Lennart Augustsson <lennart@augustsson.net> writes:

> > While I'm at it, I'll need to make usb_dma_block_t have a larger
> > array
> > of bus_dma_segment_t's. It seems like it could need as many as 16 in
> > the current arrangement (64k block from umass, 4k pages as seen by the
> > controllers). Is there anything that would want a larger transfer
> > size? Or, is 16 so large that it should be separately allocated, so it
> > can be a smaller array for smaller transfers?
> 
> 64K is the maximum.  I'm not sure 16 is large enough to warrant
> a separate allocation.

On i386, going from 1 entry to 16 entries will take usb_dma_block_t
from 44 bytes to 164 bytes. I don't quite have a sense for the
prevalence of usb_dma_block_t's to judge if that's a problem or not.

> Have you made the change for all 4 host controllers types?

I've worked on ohci and uhci so far. I'm reading up on ehci. The
fourth is that isa one (slhci)? I haven't even looked at it yet, and I
won't be able to test it.

I've actually had some difficulty testing, since when I boot a fresh
kernel with my changes, there's lots of memory avaliable; do people
have good ways to reproduce the out-of-contig-memory situation other
than "run a bunch of gui desktop apps for a while"?

        - Nathan