Re: Please revert 5adc55da4a7758021bcc374904b0f8b076508a11 (PCI_MULTITHREAD_PROBE)

[david@lang.hm]

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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/