lkml.org 
[lkml]   [2016]   [Oct]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRE: [PATCH v4 08/18] x86/intel_rdt: Pick up L3/L2 RDT parameters from CPUID
Date
> > > I wonder whether this is the proper abstraction level. We might as
> > > well do the following:
> > >
> > > rdtresources[] = {
> > > {
> > > .name = "L3",
> > > },
> > > {
> > > .name = "L3Data",
> > > },
> > > {
> > > .name = "L3Code",
> > > },
> > >
> > > and enable either L3 or L3Data+L3Code. Not sure if that makes things
> > > simpler, but it's definitely worth a thought or two.
> >
> > This way will be better than having cdp_enabled/capable for L3 and not
> > for L2. And this doesn't change current userinterface design either,
> > I think.
>
> User interface would change if you did this. The schemata file would look like
> this with CDP enabled:
>
> # cat schemata
> L3Data:0=fffff;1=fffff;2=fffff;3=fffff
> L3Code:0=fffff;1=fffff;2=fffff;3=fffff
>
> but that is easier to read than the current:
>
> # cat schemata
> L3:0=fffff,fffff;1=fffff,fffff;2=fffff,fffff;3=fffff,fffff
>
> which gives you no clue on which mask is code and which is data.

Right.

Also changing to uniform format <resname>:<id1>=cbm1;<id2>=cbm2;...
is lot easier to parse schemata line in CDP mode.

So I'll change the code and doc to have two new resources: L3Data and L3Code for CDP mode.

>
> We'd also end up with "info/L3Data/" and "info/L3code/"
> which would be a little redundant (since the files in each would contain the
> same numbers), but perhaps that is worth it to get the better schemata file.
>
> -Tony

\
 
 \ /
  Last update: 2016-10-17 18:44    [W:0.098 / U:0.264 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site