Re: Cache Allocation Technology Design

[Tejun Heo]

Hello, Tim.

On Thu, Oct 30, 2014 at 03:35:44PM -0700, Tim Hockin wrote:
> I think the conversation is well enough understood by the people for
> whom this bit of snark was intended that reading my mind was not that

I really don't think it is.  cgroups in general isn't that well
understood and while some may be familiar with what they've been
working on, most aren't too well acquainted what changes are made and
why.  I surely am responsible for not being better at communicating
but it took me quite a while and I'm still in the process of
crystalizing those myself.

> hard.  That said, it was overly snark-tastic, and sent in haste.

The problem with this type of snarky one liner is that it undermines
the fundamentals of techunical discussions on the mailing list.  It
requires too much effort on the other party for speculation and if the
other party doesn't repond, the snark comment succeeds at establishing
the vague negativity that it carried.  If you have a technical
opinion, form and communicate it properly so that it can be analyzed
and discussed properly.  I think my wording in my previous messages
was too strong and apologize for that but please don't do this.

> My point, of course, was that here is an example of something which
> maps very well to the idea of cgroups (a set of processes that share
> some controller) but DOES NOT map well to the unified hierarchy model.

I'm pretty sure that conclusion is premature.  As I wrote in my reply
to Peter, I strongly believe that a set of reasonable constraints and
conventions lead to a much better and more functional design,
interface and implementation.  It sure can feel like an annoyance if
one used to be accustomed to doing whatever and now has to follow
these new constraints but we were paying heavily elsewhere for the
lack of consistency and, in general, sense.

I could have communicated it clearer but the fundamental issue that I
see with the original proposal is that it conflates task organization
and controller configuration.  They belong to different planes of
control and should be orthogonal as much as possible.  This shows up
evidently, for example, in how errors are reported.  A write to a knob
of the involved controller failing with the proper error code is a far
superior way compared to failing mkdir or task migration.  The only
reason we even think that doing anything else is fine is because we've
never thought about what's the right thing to do all along and just
did whatever is convenient in terms of immediate implementation for
each individual case.

> It must be managed more carefully than arbitrary hierarchy can
> enforce.  The result is the mish-mash of workarounds proposed in this
> thread to force it into arbitrary hierarchy mode, including this
> no-win situation of running out of hardware resources - it is going to
> fail.  Will it fail at cgroup creation time (doesn't scale to
> arbitrary hierarchy) or will it fail when you add processes to it
> (awkward at best) or will it fail when you flip some control file to
> enable the feature?

Please see above.  It's more of the process of finding the *right*
place to put operations and their failures.  Task migration sure can
fail due to memory pressure or basic cgroup organizational contraints;
however, it's outright wrong to fail it because a given controller can
support only limited number of configurations.  Again, being able to
do whatever one wanna do often doesn't lead to a good design.

> I know the unified hierarchy ship has sailed, so there's not
> non-snarky way to argue the point any further, but this is such an
> obvious case, to me, that I had to say something.

If you properly compose your ideas and concerns, I can think about and
discuss them and make adjustments where appropriate and it seems to me
that your impression at least in this instance isn't very well
warranted.  The snark comment can achieve none of the productive
things which can come from proper discussions.  All it can do is
aggravating the tone of the discussion, so, again, please refrain from
it in the future.

Thanks.

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