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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <alpine.DEB.2.20.1610180103330.6407@nanos>
Date:   Tue, 18 Oct 2016 01:20:36 +0200 (CEST)
From:   Thomas Gleixner <tglx@...utronix.de>
To:     Fenghua Yu <fenghua.yu@...el.com>
cc:     "H. Peter Anvin" <h.peter.anvin@...el.com>,
        Ingo Molnar <mingo@...e.hu>, Tony Luck <tony.luck@...el.com>,
        Peter Zijlstra <peterz@...radead.org>,
        Stephane Eranian <eranian@...gle.com>,
        Borislav Petkov <bp@...e.de>,
        Dave Hansen <dave.hansen@...el.com>,
        Nilay Vaish <nilayvaish@...il.com>, Shaohua Li <shli@...com>,
        David Carrillo-Cisneros <davidcc@...gle.com>,
        Ravi V Shankar <ravi.v.shankar@...el.com>,
        Sai Prakhya <sai.praneeth.prakhya@...el.com>,
        Vikas Shivappa <vikas.shivappa@...ux.intel.com>,
        linux-kernel <linux-kernel@...r.kernel.org>, x86 <x86@...nel.org>
Subject: Re: [PATCH v4 13/18] x86/intel_rdt: Add mkdir to resctrl file
 system

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