Messages in this thread | | | Date | Wed, 18 Mar 2015 19:24:01 -0400 | From | Tejun Heo <> | 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
| |