Alan Cox writes:
>If you are doing DMA off the stack your code will not work on anything but
>x86 and maybe alpha in some cases.
As far as I can tell, all PCI USB drivers do
pci_{,un}map_single, so they should work. I suspect all real non-PCI
USB controllers are either on a bus that can access all main memory or
are specific to an architecture that is known to allocate the kernel
stack in an area that is accessible to that controller (I believe all
architectures currently in Linus's tree allocate the kernel stacks by
alloc_task_struct calling __get_free_pages, which is explicitly OK for
at least PCI-based DMA according to Documentation/DMA-mapping.txt).
You seem to want to optimize for what I believe is nonexistent
hardware, and also for the future ability to allocate kernel stack
pages from regions of memory that are not accessible from the USB
controllers (i.e., usually PCI). Kernel stacks are typically only
4kB, and there are typically only 100 or so processes. Even on a
system running 40,000 processes, you're only talking about 1% of the
space addressable by 32-bit PCI. That does not sound like a very
useful benefit.
Needing to assemble some little request packet quickly is
common to general purpose packet-oriented peripheral busses (not just
the control pipe, not just USB). These busses are getting much faster
relative to CPU's and their performance is becoming more of an issue
as people put more demanding hardware across them, like disk, network,
and digital video. I think this usage is common enough and important
enough that its worth optimizing some kernel programming interfaces
for it, especially since all architectures currently appear to support
this optimization anyhow.
In the specific case of usb_control_msg, this optimization
will be of increasing importance because it can be extended. At some
point, I would like to rename usb_internal_control_msg() to
usb_control() and export that interface so that, in the common case of
commands that computable at compile time (including byte swapping), I
can just pass a pointer to the precomputed command, and have never
have the CPU read it. This requires pointing the USB controllers at
kernel read only data. For packets that have to be computed at run
time, they could be built on the stack without the extra call to
usb_internal_control_msg.
I invite anyone who disagrees with this tradeoff to do
the following:
1. Identify one real hardware configuration where the USB
controller cannot read the kernel stack or kernel read-only
data by at least one of virt_to_bus (non-PCI controllers) or
pci_{,un}map_single (PCI-based controllers).
2. Show a greater performance cost for guaranteeing that the
kernel stack and kernel read only data are accessible in
this way (i.e., the cost of eliminating the case you show
in #1) than the benefit of eliminating the kmalloc (and,
later, eliminating the copy and byte swapping in some cases).
(Linux goes to some trouble to keep kernel stacks small.
The USB controllers being able to DMA from it should
be one of the rewards for this.)
If you really want to support the theoretical case of the USB
controller unable to read from kernel read only data or kernel stack,
then maybe we should think about having some macros to accomodate it
so they can be compiled out on architectures that do not have this
problem--i.e., probably all hardware people are actually using. Users
do not need to pay performance costs on real platforms to support
nonexistent platforms.
Adam J. Richter __ ______________ 4880 Stevens Creek Blvd, Suite 104
[EMAIL PROTECTED] \ / San Jose, California 95129-1034
+1 408 261-6630 | g g d r a s i l United States of America
fax +1 408 261-6631 "Free Software For The Rest Of Us."
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
