lkml.org 
[lkml]   [2002]   [Jan]   [2]   [last100]   RSS-feed
Views: [more markup]  [less markup]  [headers]  [forward] 
 
Messages in this thread
Complete thread (EXPERIMENTAL)
/
DateWed, 2 Jan 2002 10:30:15 +0100
FromJens Axboe <>
SubjectRe: [linux-usb-devel] Re: "sr: unaligned transfer" in 2.5.2-pre1
Digg This
On Tue, Jan 01 2002, Matthew Dharm wrote:
On Tue, Jan 01, 2002 at 11:34:23PM +0100, Jens Axboe wrote:
On Tue, Jan 01 2002, David Brownell wrote:
Not that I've seen a writeup about highmem (linux/Documentation doesn't seem to have one anyway) but if I infer correctly from that DMA-mapping.txt writeup, URBs don't support it because there's no way to specify buffers as a "struct page *" or an array of "struct scatterlist". That's the only way that document identifies to access "highmem memory".

This sounds like another good reason to have URBs take scatterlists directly, oddly enough. :)

Or at least a derived structure, however it might as well just use scatterlist (address member is soon gone). So yes.

(1) Do the USB HCDs support highmem? I seem to recall they do, but I'm not certain.

If URBs can't describe highmem, the HCD's won't support them per se; you'd have to turn highmem to "lowmem" or whatever it's called, and then let the HCDs manage the lowmem-to-dma_addr_t mappings.
Alternatively, in 2.5 we might add "highmem" support to USB. Now that I've looked at it a few minutes, I suspect we must -- just to support block devices (usb-storage) fully. Is there more to it than adding

No, you can always ask to get pages low mem bounced. Highmem is no requirement, and if your device really can't support it there's no point in attempting to support it.

I presume there is some overhead in bouncing to lowmem? I imagine that highmem support for the HCDs wouldn't be that difficult -- they are just PCI devices, after all.

Lots of overhead required for copying data back and forth between low and high page (both the memcpy, but also the highmem kmap). In addition it puts added pressure on the memory allocator.

I'd rather eliminate as much overhead as possible -- I already get complaints from performance fanatics about the inability of usb-storage to get past 92% bus saturation (sustained), and the problem will only get worse on USB 2.0

Then you should move the the page/len/offset construct.

page+offset as an alternative way to describe the transfer_buffer?

no

Hrm... isn't that what one of the patches sent did? Or does that only work for lowmem allocations described by the structure?

Hmmm no, I don't think so. It only worked for low mem pages, since it used page_address to 'map' the page.

-- 
Jens Axboe

\
ISP Services
Valid XHTML 1.0!\ /
Valid CSS! Last update: 2005-03-22 12:15    [W:0.416 / U:0.230 seconds]
©2003-2005 Jasper Spaans