contiguous memory allocation problem

[Peter Jeremy]

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.

>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 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.  "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).

-- 
Peter Jeremy
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20060701/2dd95200/attachment.pgp