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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 18 Mar 2015 19:24:01 -0400
From:	Tejun Heo <tj@...nel.org>
To:	Dmitry Torokhov <dmitry.torokhov@...il.com>
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

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?

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
some obscure boot flag that only several users know and exploit which
makes the kernel behave very differently.

Thanks.

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