Messages in this thread | | | Date | Thu, 6 Nov 2014 09:20:59 -0800 (PST) | From | Vikas Shivappa <> | Subject | Re: Cache Allocation Technology Design |
| |
On Thu, 6 Nov 2014, Matt Fleming wrote:
> On Thu, 30 Oct, at 11:47:40PM, Peter Zijlstra wrote: >> >> Let me reply to just this one, I'll do the rest tomorrow, need sleeps. >> >> On Thu, Oct 30, 2014 at 06:22:36PM -0400, Tejun Heo wrote: >> >>>>> This controller might not even require the distinction between >>>>> configured and effective tho? Can't a new child just inherit the >>>>> parent's configuration and never allow the config to become completely >>>>> empty? >>>> >>>> It can do that. But that still has a problem, there is a mapping in >>>> hardware which restricts the number of active configurations. The total >>>> configuration space is larger than the supported active configurations. >>>> >>>> So _something_ must fail. The initial proposal was mkdir failing when >>>> there were more than the hardware supported active config cgroup >>>> directories. The alternative was on-demand activation where we only >>>> allocate the hardware resource when the first task gets moved into the >>>> group -- which then clearly can fail. >>> >>> Hmmm... why can't it just refuse creating a different configuration >>> when its config space is full? Make children inherit the parent's >>> configuration and refuse config writes which require it to create a >>> new one if the config space is full. Seems pretty straight-forward. >>> What am I missing? >> >> We could do that I suppose, there is the one corner case that would not >> allow, intermediate directories with a restricted config that also have >> priv restrictions but no actual tasks. Not sure that makes sense though. > > Could you elaborate on this configuration? > >> Are there any other cases I might have missed? > > I don't think so. > > So, for the specific CAT case what you're proposing is make the failure > case happen when writing to the cache bitmask file instead of failing > mkdir() or echo $tid > tasks ? > > I think that's OK. If we've run out of CLOS ids I would expect to see > -ENOSPC returned, whereas if we try and set an invalid bitmask we'd get > -EINVAL. > > Vikas, Will?
Yes that is correct. You can always create more cgroups and the new cgroup just inherits the mask from the parent and uses the same CLOSid as its parent , so it wont fail because of lack of CLOSids.
The only case of failure as you said is when user tries to modify a cbm to a different one.
> > -- > Matt Fleming, Intel Open Source Technology Center >
| |