Re: Please revert 5adc55da4a7758021bcc374904b0f8b076508a11(PCI_MULTITHREAD_PROBE)
From: david
Date: Wed May 09 2007 - 12:53:30 EST
On Wed, 9 May 2007, Greg KH wrote:
doesn't take long, having all devices probed one after the other may
take a lot of time. Putting the actual probe on a thread makes it
possible to run several probes in parallel, thereby cutting probing
time.
Again, not for PCI, right?
It seems that everyone agrees now that moving PCI over to a new probing
model without individual driver support was a bad idea. So generic
multithreaded probing is dead.
Why is it dead? Since when is PCI the only bus in the system?
correct, while this discussion started over the PCI_MULTITHREAD_PROBE it's
focusing on the generic problem that would apply to any bus
If you want to implement this for your bus type, fine, I have no
objection to that at all, but not for PCI, it's just not worth it.
Infrastructure for async probing might not be such a bad idea, though.
(Aren't there some huge PCI-based machines?) However, I don't really
care whether PCI or SCSI or $HUGE_BUS use it, but serial synchronous
probing on a bus looks like a killer on most large systems.
PCI probing is just reading stuff from memory. The slowness happens
when storage devices need to spin up and/or discover attached drives.
So, the async stuff can be done in those buses if wanted/needed, PCI is
not the problem here.
I don't think anyone is saying that PCI is the problem here. We're trying
to identify what needs to be done for any arbatrary bus, if a particular
bus doesn't need to split it's initialization up becouse there are no
delays (and therefor no gains for multithreading) then drivers for that
bus don't bother to implement any async portion.
David Lang
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/