linux-kernel - Re: [PATCH v3 05/18] Documentation, x86: Documentation for Intel resource allocation user interface

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: <CACbG30-oAftpUZ0K0VdtN-HacWiQfD8ZXU5EvY_NYB4Vsr0gUQ@mail.gmail.com>
Date:   Tue, 11 Oct 2016 12:07:33 -0500
From:   Nilay Vaish <nilayvaish@...il.com>
To:     "Luck, Tony" <tony.luck@...el.com>
Cc:     Fenghua Yu <fenghua.yu@...el.com>,
        Thomas Gleixner <tglx@...utronix.de>,
        "H. Peter Anvin" <h.peter.anvin@...el.com>,
        Ingo Molnar <mingo@...e.hu>,
        Peter Zijlstra <peterz@...radead.org>,
        Stephane Eranian <eranian@...gle.com>,
        Borislav Petkov <bp@...e.de>,
        Dave Hansen <dave.hansen@...el.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 v3 05/18] Documentation, x86: Documentation for Intel
 resource allocation user interface

On 10 October 2016 at 12:19, Luck, Tony <tony.luck@...el.com> wrote:
> On Sat, Oct 08, 2016 at 01:33:06PM -0700, Fenghua Yu wrote:
>> On Sat, Oct 08, 2016 at 12:12:07PM -0500, Nilay Vaish wrote:
>> > On 7 October 2016 at 21:45, Fenghua Yu <fenghua.yu@...el.com> wrote:
>> > > From: Fenghua Yu <fenghua.yu@...el.com>
>> > >
>> > > +L3 details (code and data prioritization disabled)
>> > > +--------------------------------------------------
>> > > +With CDP disabled the L3 schemata format is:
>> > > +
>> > > +       L3:<cache_id0>=<cbm>;<cache_id1>=<cbm>;...
>> > > +
>> > > +L3 details (CDP enabled via mount option to resctrl)
>> > > +----------------------------------------------------
>> > > +When CDP is enabled, you need to specify separate cache bit masks for
>> > > +code and data access. The generic format is:
>> > > +
>> > > +       L3:<cache_id0>=<d_cbm>,<i_cbm>;<cache_id1>=<d_cbm>,<i_cbm>;...
>> >
>> > Can we drop L3 here and instead say:
>> > L<level>:<cache_id0>=<d_cbm>,<i_cbm>;<cache_id1>=<d_cbm>,<i_cbm>;...
>> >
>> > and similarly for without CDP as well.
>>
>> L3 and L2 are similar but different. L2 doesn't have CDP feature. It would
>> be better to talk them separately here.
>>
>
> Perhaps we should document the general form, and then show examples
> for L3 (and later L2 and other resources as they are added). Note
> in particular that other resources are not cache-like ... so the
> pattern you see between L3 and L2 is short lived. Future resources
> that can be controlled are not caches.
>
> General form of a resource line is:
>
> {resource type}:[{resource instanceM}={resource value};]*N
>
> where "M" iterates over all online instances of this resource,
> and "N" is the total number. [and the ";" is a separator, not a terminator,
> but I'm not sure how to write that].
>
> For the "L3" resource there are two formats for the value.
> With CDP enabled:
>         {d-cache bit mask},{i-cache bit mask}
> with CDP disabled:
>         {cache bit mask}


I am in favour of documenting the general form, but Fenghua and you
can take a call on this.

>
> "L2" resource doesn't support CDP, so the only format is {cache bit mask}
>
>
> The next resource coming will have values that are simple ranges {0 .. max}
>

Regarding addition of more resources, I was wondering if one common
definition of struct rdt_resource to be used for each resource the way
to take.  As you point out, L2 caches will not support CDP, but cdp
would be part of the variable describing L2 cache.  Should we have
separate structs for each resource?

--
Nilay