Re: [PATCH V16 11/11] x86,cgroup/intel_rdt : Add a cgroup interface to manage Intel cache allocation

[Marcelo Tosatti]

On Sat, Dec 19, 2015 at 11:42:57AM +0100, Thomas Gleixner wrote:
> On Thu, 17 Dec 2015, Fenghua Yu wrote:
> 
> > From: Fenghua Yu <fenghua.yu@xxxxxxxxx>
> > 
> > From: Vikas Shivappa <vikas.shivappa@xxxxxxxxxxxxxxx>
> > 
> > Add a new cgroup 'intel_rdt' to manage cache allocation. Each cgroup
> > directory is associated with a class of service id(closid). To map a
> > task with closid during scheduling, this patch removes the closid field
> > from task_struct and uses the already existing 'cgroups' field in
> > task_struct.
> > 
> > The cgroup has a file 'l3_cbm' which represents the L3 cache capacity
> > bitmask(CBM). The CBM is global for the whole system currently. The
> > capacity bitmask needs to have only contiguous bits set and number of
> > bits that can be set is less than the max bits that can be set. The
> > tasks belonging to a cgroup get to fill in the L3 cache represented by
> > the capacity bitmask of the cgroup. For ex: if the max bits in the CBM
> > is 10 and the cache size is 10MB, each bit represents 1MB of cache
> > capacity.
> > 
> > Root cgroup always has all the bits set in the l3_cbm. User can create
> > more cgroups with mkdir syscall. By default the child cgroups inherit
> > the capacity bitmask(CBM) from parent. User can change the CBM specified
> > in hex for each cgroup. Each unique bitmask is associated with a class
> > of service ID and an -ENOSPC is returned once we run out of
> > closids.
> 
> This is still the original crap. No, we are not introducing this
> interface now just because we can. I explained in great length why
> this is completely useless and what we really need.
> 
> Thanks,
> 
> 	tglx

Can you make a summary of the points, and enumerate them, please.
(what are the problems of the current interface, and why such problems
are fixed in the new interface?).

Then someone can write it, integrate it, and everyone is happy.



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