On Wed, Mar 18, 2015 at 05:50:28PM -0400, Tejun Heo wrote: > Hello, Dmitry. > > On Wed, Mar 18, 2015 at 02:41:26PM -0700, Dmitry Torokhov wrote: > > You are over-stating the boot order guarantees that storage provides. > > Yes, you can scan devices and partitions simultaneously on the same > > controller, but it will break if controllers are registered in different > > order. And if you are delaying registering cone controller because > > another that you consider "first" has not done probing, you are stalling > > the boot process. It may be OK for "leaf" devices, which disks are > > usually are, bit not when you delaying initialization of a device that > > is in a middle of the device tree. > > Can't we make it "transitive"? Split ->probe() into two parts so that > attaching the leaf devices run from the completion part of the split > ->probe(). Sure, a lot of userlands we have nowadays can handle probe > order changing but we stil have use cases where the order matters. > Why introduce two separate behaviors when we can make the pararell > ordering transitive?
So let's say that we we have 2 devices D1 and D2 which have children C1 and C2 with leaves L1 and L2: Device Probe time D1 5 D2 1 C1 2 C2 4 L1 1 L2 1 If we run fully async we will need 8 units to probe everything (max(D1+C1+L1, D2+C2+L2)). With pausing at each level we'd need 10 units (max(D1, D2) + max(C1, C2) + max(L1, L2). > > Doing things based on a big switch is going to create two largely > separate modes of operations. For a lot of cases, the gain in boot > time might not be enough to turn on the switch and we sure can't > default to turning it on. This is a deviation we can avoid with > reasonable amount of effort. The trade-off seems pretty clear to me. As I mentioned, the benefit / trade-off depends on your point of view. For servers nobody would care. For consumer devices it is very important. Thanks. -- Dmitry -- 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/
