> > The pci_pool calls will need a tweak; they test for SLAB_KERNEL,
> > but SLAB_NOIO should work there too.
>
> Explain please.
The HCDs use the pci_pool_alloc() calls, which has substantially
improved their portability to non-x86 systems (with "interesting" PCI
DMA restrictions), but that wasn't originally set up to handle anything
except SLAB_KERNEL and SLAB_ATOMIC as mem_flags values.
I think it'd suffice to change the "== SLAB_KERNEL" check there
(look at the end of drivers/pci/pci.c) to check if the __GFP_WAIT
bit is set. A one-line change.
> > Some USB APIs will be trouble, since they don't pass an URB
> > or explicit mem_flags value down. Were you thinking of just
> > making it all use SLAB_NOIO? That might cause a few more
>
> These are usb_control_message() and usb_clear_halt(). I was thinking
> of doing a version for block devices that uses NOIO. Thus compatibility is
> maintained in 2.4 and in 2.5 we'd merge and add another parameter to the call.
What did you think of Alan's notion of basically wrapping this
option up as a device flag rather than a per-request flag, at
least as a near term solution?
Long term I think per-request options here are essential.
Near term, flagging this at the device level may well be
the least invasive solution.
> > "out of memory" error reports in places it's not necessary (khubd
> > as one example). But I'm not sure making usb_control_msg() and
> > all its callers (and their callers ... :) take a new mem_flags parameter
> > would be a reasonable API change.
>
> Which leads to the question whether another parameter to usb_submit_urb()
> would be acceptable, too.
usb_submit_urb() or usb_allocate_urb()? If there's a flag inside
the URB that says use NOIO, no new parameter is needed when
it's submitted.
> We could get rid of the in_interrupt() checks in
> the host controler drivers, too.
Everywhere. The in_interrupt() logic isn't sufficient anyway; anyone can
call such routines while holding a lock and !in_interrupt(), then code that
relies on that logic will conclude that it's OK to sleep (even NOIO) when
in fact it really isn't.
There are some error checks for in_interrupt() that should stay. For
example, synchronous unlinking while in_interrupt() is deeply evil.
> Still we still deadlock if GFP_NOIO fails in swapping.
Deadlock? Or just fail? Not the same.
> We need a small pool
> of free pages which GFP_NOIO will be serviced from and GFP_ATOMIC won't be
> serviced from.
That's not a USB-only problem though. And I'm not sure I see why
the 'emergency pools' shared by GFP_ATOMIC and GFP_NOIO
shouldn't be shared. (That's "__GFP_HIGH" ...)
- Dave
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
