linux-kernel - Re: Cache Allocation Technology Design

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]

Message-ID: <CAAAKZwsGs4e1T8Xb=kEGY3O=ZJS4DgOe7Oi5UPUXz5cwiRcH9g@mail.gmail.com>
Date:	Thu, 30 Oct 2014 15:35:44 -0700
From:	Tim Hockin <thockin@...kin.org>
To:	Tejun Heo <tj@...nel.org>
Cc:	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"Auld, Will" <will.auld@...el.com>,
	Matt Fleming <matt@...sole-pimps.org>,
	Vikas Shivappa <vikas.shivappa@...ux.intel.com>,
	Peter Zijlstra <peterz@...radead.org>,
	"Fleming, Matt" <matt.fleming@...el.com>,
	Vikas Shivappa <vikas.shivappa@...el.com>
Subject: Re: Cache Allocation Technology Design

On Thu, Oct 30, 2014 at 10:12 AM, Tejun Heo <tj@...nel.org> wrote:
> On Thu, Oct 30, 2014 at 07:58:34AM -0700, Tim Hockin wrote:
>> Another reason unified hierarchy is a bad model.
>
> Things wrong with this message.
>
> 1. Top posted.  It isn't clear which part you're referring to and this
>    was pointed out to you multiple times in the past.

I occasionally fall victim to gmail's defaults.  I apologize for that.

> 2. No real thoughts or technical details.  Maybe you had some in your
>    head but nothing was elaborated.  This forces me to guess what you
>    had on mind when you produced the above sentence and of course me
>    not being you this takes a considerable amount of brain cycle and
>    I'd still end up with multiple alternative scenarios that I'll have
>    to cover.

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
hard.  That said, it was overly snark-tastic, and sent in haste.

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.
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?

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.

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