Re: [PATCH 6/8] amd64_edac: enforce synchronous probe

[Dmitry Torokhov]

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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/