Re: Cache Allocation Technology Design

[Tejun Heo <tj@kernel.org>]

Hello, Peter.

On Thu, Oct 30, 2014 at 08:07:25AM +0100, Peter Zijlstra wrote:
> If this means echo $tid > tasks, then sorry we can't do. There is a
> limited number of hardware resources backing this thing. At some point
> they're consumed and something must give.

And that something shouldn't be disallowing task migration across
cgroups.  This simply doesn't work with co-mounting or unified
hierarchy.  cpuset automatically takes on the nearest ancestor's
configuration which has enough execution resources.  Maybe that can be
an option for this too?

One of the problems is that we generally assume that a task can run
some point in time in a lot of places in the kernel and can't just not
run a task indefinitely because it's in a cgroup configured certain
way.

> So either we fail mkdir, but that means allocating CLOS IDs for possibly
> empty cgroups, or we allocate on demand which means failing task
> assignment.

Can't fail mkdir or css enabling either.  Again, co-mounting and
unified hierarchy.  Also, the behavior is just horrible to use from
userland.

> The same -- albeit for a different reason -- is true of the RT sched
> groups, we simply cannot instantiate them such that tasks can join,
> sysads _have_ to configure them before we can add tasks to them.

Yeah, RT is one of the main items which is problematic, more so
because it's currently coupled with the normal sched controller and
the default config doesn't have any RT slice.  Do we completely block
RT task w/o slice?  Is that okay?

Thanks.

-- 
tejun