lkml.org 
[lkml]   [2007]   [May]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: Please revert 5adc55da4a7758021bcc374904b0f8b076508a11 (PCI_MULTITHREAD_PROBE)
    On Tue, 8 May 2007, Cornelia Huck wrote:

    > 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.)

    I have used userspace tools for managing multiple machines that spawn
    tasks in parallel on multiple machines and then buffers them per-machine
    to display the output of the commands in order, no matter which one
    finished first.

    for example 'dsh m1,m2 ls /' would always result in

    m1 .
    m1 ..
    .
    .
    m2 .
    m2 ..
    .
    .

    even if m2 finished before m1

    why can't the detection be done in parallel, but the regestration of
    detected devices be done in order?

    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/

    \
     
     \ /
      Last update: 2007-05-08 18:53    [W:4.560 / U:0.000 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site