Sent: Mon, 17 Jan 2011 From: Arjan van de Ven<arjan@xxxxxxxxxxxxxxx> > On 1/15/2011 11:33 PM, Dirk Behme wrote: > > > > Do you talk about > > > > > http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdif > f;h=22a9d645677feefd402befd02edd59b122289ef1 > > > > > http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h= > 4ace92fc112c6069b4fcb95a31d3142d4a43ff2a > > > > > http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h= > 793180570ff2530d133343ceea85648de5f01b02 > > > > > http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h= > f29d3b23238e1955a8094e038c72546e99308e61 > > > > > > http://lwn.net/Articles/314808/ > > > > merged with 2.6.29? > > > > With a recent .37 kernel the usage of async_schedule() seems to be > > implemented for > > yep > > > > ./drivers/acpi/battery.c > > ./drivers/s390/block/dasd.c > > ./drivers/base/power/main.c > > ./drivers/ata/libata-core.c > > ./drivers/scsi/sd.c > > ./drivers/md/raid5.c > > > > With this, on an embedded system using none of this, the completely > > single-threaded start up reported in [2] seems to be reasonable, then? > > quite likely. > > > > > This would mean that to improve the issues reported in [2], > > async_schedule() has to be implemented for the sub systems used, > > there, too? I.e. the USB init? > > USB init is asynchronous internal to USB; this was one of the outcomes > of a side discussion at the Kernel Summit a year and a half ago or so > where Alan Stern visualized the problem... and solved it internal to USB. > > Now, there is one 100 msec delay that is inherent to USB (mandatory > delay required by the spec for voltage to stabilize) but that shouldn't > be in the synchronous path anymore There is a 100ms electrical/mechanical root debounce delay from USB specification that is indeed avoided by [1]. What we see is that there are two (EHCI + OHCI) additional 50ms root port reset delays required by USB spec resulting in an 100ms delay. Seems that these two are synchronous(?) See bootgraph pictures attached. > >>> what kernel are you seeing issues on? > >> > >> [1] talks about 2.6.28, [2] talks about 2.6.34. > > yeah 2.6.28 is a lost cause ;-) 2.6.34 should be not too bad. > > Now, the one thing that's critical for all of this is that we need to do > this data driven. Using async init is not always as easy as it sounds; > there are device ordering things that need to be dealt with, and failure > cases get much more complex as well. > > So the first order of business ALWAYS is to get a bootgraph (from > scripts/bootgraph.pl)... to see which things are big on the one hand, > but also to see if there is gains to be had. There is absolutely no gain > possible (in terms of making something async) if it is pretty much the > last big thing in the boot that you are making asynchronous (since the > end of kernel boot has to wait for it all anyway); there is only gains > for async if the expensive operation, when made async, can run in > parallel with something else expensive that comes later in the kernel init. > > The bootgraph will show this opportunity / pitfall very clearly...... Please find in the attachment two bootgraphs from the 2.6.34 system discussed in [2]. The first is from the unmodified boot. The second with having "fastboot: turn the USB hostcontroller initcalls into async initcalls" applied. Does this make sense? Many thanks and best regards Martin [1] http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=8520f38099ccfdac2147a0852f84ee7a8ee5e197 [2] http://thread.gmane.org/gmane.linux.usb.general/41181
Attachment:
bootgraph_2_6_34_arjan_usb_fastboot.png
Description: PNG image
Attachment:
bootgraph_2_6_34_umodified.png
Description: PNG image
