[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.DEB.2.21.1802271553560.1886@nanos.tec.linutronix.de>
Date: Tue, 27 Feb 2018 16:38:59 +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 Tue, 27 Feb 2018, Thomas Gleixner wrote:
> On Mon, 26 Feb 2018, Reinette Chatre wrote:
> > Moving to "exclusive" mode it appears that, when enabled for a resource
> > group, all domains of all resources are forced to have an "exclusive"
> > region associated with this resource group (closid). This is because the
> > schemata reflects the hardware settings of all resources and their
> > domains and the hardware does not accept a "zero" bitmask. A user thus
> > cannot just specify a single region of a particular cache instance as
> > "exclusive". Does this match your intention wrt "exclusive"?
>
> Interesting question. I really did not think about that yet.
Actually we could solve that problem similar to the locked one and share
most of the functionality:
mkdir group
echo exclusive > mode
echo L3:0 > restrict
and for locked:
mkdir group
echo locksetup > mode
echo L2:0 > restrict
echo 'L2:0=0xf' > schemata
echo locked > mode
The 'restrict' file (feel free to come up with a better name) is only
available/writeable in exclusive and locksetup mode. In case of exclusive
mode it can contain several domains/resources, but in locked mode its only
allowed to contain a single domain/resource.
A write to schemata for exclusive or locksetup mode will apply the
exclusiveness restrictions only to the resources/domains selected in the
'restrict' file.
Thanks,
tglx
Powered by blists - more mailing lists