Re: [PATCH v4 13/18] x86/intel_rdt: Add mkdir to resctrl file system

[Thomas Gleixner]

On Mon, 17 Oct 2016, Fenghua Yu wrote:
> part0: L3:0=1;1=1       closid0/cbm=1 on cache0 and closid0/cbm=1 on cache1
> (closid 15 on cache0 combined with 16 different closids on cache1)
> ...
> part254: L3:0=ffff;1=7fff   closid15/cbm=ffff on cache0 and closid14/cbm=7fff on cache1
> part255: L3:0=ffff;1=ffff   closid15/cbm=ffff on cache0 and closid15/cbm=ffff on cache1
> 
> To utilize as much combinations as possbile, we may implement a
> more complex allocation than current one.
> 
> Does this make sense?

Thanks for the explanation. I knew that I'm missing something.

But how is that supposed to work? The schemata files have no idea of
closids simply because the closids are assigned automatically. And that
makes the whole thing exponentially complex. You must allow to create ALL
rdt groups (initialy as a copy of the root group) and then when the
schemata file is written you have to look whether the particular CBM value
for a particular domain is already used and assign the same cosid for this
domain. That of course makes the whole L2 business completely diffuse
because you might end up with:

Dom0 = COSID1	  and DOM1 = COSID9

So you can set the L2 for Dom0, but not for DOM1 and then if you set L2 for
Dom0 you must find a new COSID for Dom0. If there is none, then you must
reject the write and leave the admin puzzled.

There is a reason why I suggested:

 https://lkml.kernel.org/r/alpine.DEB.2.11.1511181534450.3761@nanos

It's certainly not perfect (missing L2 etc.), but clearly avoids exactly
the above issues. And it would allow you to utilize the 256 groups in an
understandable way.

Thanks,

	tglx