Messages in this thread | | | From | Tim Hockin <> | Date | Thu, 30 Oct 2014 15:35:44 -0700 | Subject | Re: Cache Allocation Technology Design |
| |
On Thu, Oct 30, 2014 at 10:12 AM, Tejun Heo <tj@kernel.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
| |