linux-kernel - Re: Please revert 5adc55da4a7758021bcc374904b0f8b076508a11 (PCI_MULTITHREAD

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20070508183846.28a94797@gondolin.boeblingen.de.ibm.com>
Date:	Tue, 8 May 2007 18:38:46 +0200
From:	Cornelia Huck <cornelia.huck@...ibm.com>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	Adrian Bunk <bunk@...sta.de>, Greg K-H <greg@...ah.com>,
	linux-kernel <linux-kernel@...r.kernel.org>
Subject: Re: Please revert 5adc55da4a7758021bcc374904b0f8b076508a11
 (PCI_MULTITHREAD_PROBE)

On Tue, 8 May 2007 08:27:34 -0700 (PDT),
Linus Torvalds <torvalds@...ux-foundation.org> 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 majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/