Date:	Wed, 18 Mar 2015 17:26:19 -0700
From:	Dmitry Torokhov <dmitry.torokhov@...il.com>
To:	Tejun Heo <tj@...nel.org>
Cc:	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	"Luis R . Rodriguez" <mcgrof@...e.com>,
	linux-kernel@...r.kernel.org,
	Arjan van de Ven <arjan@...ux.intel.com>,
	Rusty Russell <rusty@...tcorp.com.au>,
	Olof Johansson <olof@...om.net>,
	Tetsuo Handa <penguin-kernel@...ove.SAKURA.ne.jp>
Subject: Re: [PATCH 6/8] amd64_edac: enforce synchronous probe

On Wed, Mar 18, 2015 at 07:24:01PM -0400, Tejun Heo wrote:
> Hello, Dmitry.
> 
> On Wed, Mar 18, 2015 at 03:15:30PM -0700, Dmitry Torokhov wrote:
> > 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).
> 
> Yeah, the details will differ depending on the specifics of layering
> but it's likely to add more synchronization points.
> 
> > > 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.
> 
> Shouldn't we still be able to extract most of parallelism this way,
> especially given that as the probing walks down the hierarchy, they
> get decoupled from each other?

Why would they get decoupled? For example, if we are talking about input
devices, they can be connected to platform bus or one of i2c buses or
HID (via USB). If we want to ensure ordering we'd have to synchronize
all of them somehow and I do not have even sure what the rule should be.
I mean I am probing platform devices simultaneously and I come to an
i2c controller and gpio input device. So I wait till both done probing
before posting new devices to the driver core? What if one returns
-EPROBE_DEFER? Do I stop and wait for the deferral to complete? What if
deferral is satisfied by a 3rd device on platform bus? If I am waiting
for all devices to probe I won't be able to resolve the deferral. And
even without deferral in old world we'd probe i2c and i2c will lead to
discovery of another input device which would be registered before
registering the platform input device. So with async we'd have to pause
platform probing until all children of i2c are done probing, which
pretty much kills all async gains as far as I can see.

> 
> Even if certain use cases can benefit from completely ignoring
> ordering, it's a lot more consistent to add an option to ignore device
> ordering on top of general async mechanism rather than having fully
> async vs. sync probing paths.  We'd still be traveling and testing
> most of the same logic.  What bothers me primarily is that this being

I think the logic is pretty much the same even with async probing,
especially if you take into account -EPROBE_DEFER handling that we
already have. You may not run into it that often on x86 but it is pretty
common on arm devices and it does change the probe order.

>
> some obscure boot flag that only several users know and exploit which
> makes the kernel behave very differently.

I do not think this flag is useful for end users but rather for
distributions. Either their userspace is ready to handle fully async
probe or not quite yet.

Thanks.

-- 
Dmitry
--
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/

Powered by blists - more mailing lists