linux-kernel - Re: [RFC PATCH V2 13/22] x86/intel_rdt: Support schemata write

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.21.1802281858420.1392@nanos.tec.linutronix.de>
Date:   Wed, 28 Feb 2018 18:59:24 +0100 (CET)
From:   Thomas Gleixner <tglx@...utronix.de>
To:     Reinette Chatre <reinette.chatre@...el.com>
cc:     fenghua.yu@...el.com, tony.luck@...el.com, gavin.hindman@...el.com,
        vikas.shivappa@...ux.intel.com, dave.hansen@...el.com,
        mingo@...hat.com, hpa@...or.com, x86@...nel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [RFC PATCH V2 13/22] x86/intel_rdt: Support schemata write -
 pseudo-locking core

On Wed, 28 Feb 2018, Thomas Gleixner wrote:
> On Tue, 27 Feb 2018, Reinette Chatre wrote:
> > On 2/20/2018 9:15 AM, Thomas Gleixner wrote:
> > > Let's look at the existing crtl/mon groups which are each represented by a
> > > directory already.
> > > 
> > >  - Adding a 'size' file to the ctrl groups would be a natural extension
> > >    which makes sense for regular cache allocations as well.
> > > 
> > 
> > I would like to clarify how you envision the value of "size" computed. A
> > resource group may have several resources associated with it. Some of
> > these resources may indeed overlap, for example, if there is L2 and L3
> > CAT capable resources on the system. Similarly when CDP is enabled,
> > there would be overlap in bitmasks referring to the same cache locations
> > but treated as different resources. Indeed, there may in the future be
> > some resources that are capable of allocation but not cache specifically
> > that could also be handled within a single resource group.
> > 
> > Summarizing all of these cases with a single "size" associated with the
> > resource group does not seem straightforward to me.
> 
> We have the schemata file which covers everthing. So the size file inside a
> resource group should show the sizes for each domain/resource as well.
> 
> L2:0=128K;1=256K;
> L3:0=1M;1=2M;
> 
> L3DATA:0=128K
> L3CODE:0=128K
> 
> or such. That would be consistent with the schemata file. If there are
> resources which cannot be expressed in size, like MBA then you simply do
> not print them.
> 
> At the top level you want to show the inuse areas. I'd go for straight
> bitmap display there:
> 
> L2:0=00011100;1=11111111;
> L3:0=11001100;1=11111111;
> 
> If L3 CDP is enabled then you can show:
> 
> L3:0=1DCCDC00;1=DDDD00CC;
> 
> where:
> 
> 0 = unused
> 1 = overlapping C/D
> C = code
> D = data

Hit send too early....

For the locked case this would add:

 L = locked

Thanks,

	tglx