On Tue, 8 May 2007 08:27:34 -0700 (PDT), Linus Torvalds <[EMAIL PROTECTED]> wrote:
> And no, we should not do it at the device core level. In fact, I don't > think we should do it at that level at all. > > I'm pretty sure that the performance problems are at individual device > drivers, and that the right solution is to thread at *that* level. Not > higher up. These are two different problems: 1. Probing taking long for individual device drivers. I agree, this should be solved at the driver level. 2. Sheer volume of devices on a bus. Even if the indivdual probing 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. (FWIW, the s390 cio layer does asynchronous probing at the bus level, where work is usually outstanding for a lot of devices at once. Where a 2.4 kernel might take half an hour to detect all devices, we slashed it down to half a minute. I believe we could make rescans work even better with multithreaded probing with some tweaking.) > Threading at the bus level just inevitably means things like random > numbers for devices depending on some timing/scheduling issue. That's > nasty. > > Threading at a driver level still does that (ie individual disks may be > attached in some order that depends on how fast they are to respond), but > in a much more controlled fashion, and only for drivers that explicitly > say that they can do it. How is that better? You still must rely on udev for persistent device names. And controlling device names in the driver can still be done in the device driver with multithreaded probing (on s390 ccw, devices already pop up in a random order, and the dasd driver manages to conjure up consistent names for those devices that the user specified.) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
