On Fri, 27 Oct 2006, Greg KH wrote:
>
> Heh, ok, I'll take this idea, and Andrew's patch, and rework things for
> the next round of 2.6.20-rc kernels, and mark the current stuff as
> BROKEN for now.
My interface stuff is kind of designed for:
- keep the current "init" sequence as-is for now
- keep the _actual_ PCI probing non-parallel, so that we actually do all
the bus _discovery_ in a repeatable and sane order.
- use the new "execute_in_parallel()" interface for things that actually
_sleep_. For example, all the PCI IDE _driver_ attachement should be
done synchronously, but perhaps the code that tries to see if there are
actual disks (ie the stuff that has timeouts etc) can use the parallel
execution.
- module loading would do a "allow_parallel(1)" and
"wait_for_parallel(1)" thing when calling the module init function (so
that a module could use "execute_in_parallel()" whether compiled in or
not, and each "init level" at boot would also do this (with some bigger
number, like 10), so that for drivers etc that want to do async stuff,
they can do so in parallel (but they'd still have done the actual hard
device find/init serially - keeping the link order relevant for things
like IDE controller discovery)
How does this sound?
There's really no reason to parallelise the actual PCI config cycles and
probing and stuff. It's only when some driver knows that it might have to
do some longer-running thing that it might want to execute a thread in
parallel with other things - but it still needs to be done in a controlled
situation, so that when "driver_init()" stops and "filesystem_init()"
starts, we must wait for all the driver-init parallel tasks to finish
(since "filesystem_init()" is allowed to depend on them).
Hmm?
Linus
-
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/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
