contiguous memory allocation problem

[Hans Petter Selasky]

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

--HPS