contiguous memory allocation problem
Hans Petter Selasky
hselasky at c2i.net
Sat Jul 1 13:31:09 UTC 2006
On Saturday 01 July 2006 14:34, Peter Jeremy wrote:
> On Sat, 2006-Jul-01 10:44:54 +0200, Hans Petter Selasky wrote:
> >Yes, but scatter and gather will add extra complexity to the driver, and
> > maybe an extra memory copy in most cases. The idea is to allocate less
> > than or equal to a page of memory, and then avoid the problem?
> The idea is to allocate multiple disjoint pages of physical memory.
> The USB hardware is capable of supporting this and page translation
> hides the lack of contiguousness from userland. I don't see why
> additional memory copies would be required.
Because most USB device drivers depend on a contigous buffer. In your case one
would have to implement something similar to "uiomove()" for copying, that
will do the scatter and gathering ?
> >The most important thing is to keep memory allocations of constant size.
> > For example under my USB system, all memory is allocated at attach. There
> > is no longer allocation and freeing of memory during usage, with a few
> > exceptions.
> Are you talking about USB device attach - which could happen at any
> time whilst the system is running - or USB bus attach?
I am talking about the USB device attach.
> >I was thinking I could pre-allocate 2-4MB for the USB system, then make a
> >list of freed memory blocks, and then search this list first, before
> >allocating new memory.
> That strikes me as wasteful. Currently, umass needs something like
> 64K (or maybe 128K) and ulpt needs a few KB (they are the only USB
> devices I normally use). I would be surprised if the peak USB RAM
> requirement was more than 256K for most people.
Yes, but don't forget high-speed USB transfers. They require larger buffers.
For example 1024 bytes for ULPT is too little. The interrupt rate will be so
high, that it is unrealistic to transfer 20MB/s using 1024 byte interrupts.
My rewritten ULPT now uses "2*(1<<17)" buffers.
> "vmstat -m" on my
> systems shows that the current biggest consumer is devbuf - with
> 3-4MB. Most other consumers are orders of magnitude smaller than this
> (though my video capture card grabs about 4MB RAM when it's in use).
More information about the freebsd-hackers