[lkml]   [2018]   [Feb]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [RFC PATCH V2 13/22] x86/intel_rdt: Support schemata write - pseudo-locking core
Hi Thomas,

On 2/27/2018 11:52 AM, Reinette Chatre wrote:
> On 2/27/2018 2:36 AM, Thomas Gleixner wrote:
>> Let's assume its real,
>> so you could do the following:
>> mkdir group <- acquires closid
>> echo locksetup > mode <- Creates 'lockarea' file
>> echo L2:0 > lockarea
>> echo 'L2:0=0xf' > schemata
>> echo locked > mode <- locks down all files, does the lock setup
>> and drops closid
>> That would solve quite some of the other issues as well. Hmm?
> At this time the resource group, represented by a resctrl directory, is
> tightly associated with the closid. I'll take a closer look at what it
> will take to separate them.
> Could you please elaborate on the purpose of the "lockarea" file? It
> does seem to duplicate the information in the schemata written in the
> subsequent line.
> If we do go this route then it seems that there would be one
> pseudo-locked region per resource group, not multiple ones as I had in
> my examples above.

Actually, this need not be true. It could be possible for administrator
to pseudo-lock two regions at once. For example,

mkdir group
echo locksetup > mode
echo 'L2:0=0xf;1=0xf' > schemata

This could have two pseudo-locked regions associated with a single
resource group. This does complicate the usage of the "size" file even
more though since the plan was to have a single "size" file associated
with a resource group it is not intuitive how it should describe
multiple pseudo-locked regions. I added the "size" file originally to
help users of the pseudo-locking interface where a single pseudo-locked
region existed in a directory. All information to compute the size
themselves are available to users, perhaps I can add pseudo-code to
compute the size from available information to the documentation?


 \ /
  Last update: 2018-02-27 22:34    [W:0.116 / U:9.800 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site