[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CA+8MBbLEp52B9CBE8VEzQuaLh3tKYFQpKfV=wnUMZyb07aJEHw@mail.gmail.com>
Date: Fri, 16 Dec 2016 17:44:47 -0800
From: Tony Luck <tony.luck@...il.com>
To: Thomas Gleixner <tglx@...utronix.de>
Cc: Linus Torvalds <torvalds@...ux-foundation.org>,
LKML <linux-kernel@...r.kernel.org>,
Andrew Morton <akpm@...ux-foundation.org>,
Ingo Molnar <mingo@...nel.org>,
"H. Peter Anvin" <hpa@...or.com>
Subject: Re: [GIT pull] x86/cache: Updates for 4.10
On Tue, Dec 13, 2016 at 1:01 AM, Thomas Gleixner <tglx@...utronix.de> wrote:
> On Mon, 12 Dec 2016, Linus Torvalds wrote:
>
>> On Mon, Dec 12, 2016 at 1:53 AM, Thomas Gleixner <tglx@...utronix.de> wrote:
>> Ugh, this is some funky stuff. And it's entirely x86-specific, with a
>> rather odd special filesystem interface.
>
> Yes. The interface is odd, but the hardware interface of that CAT stuff is
> odd as well.
>
> We tried hard to come up with an abstraction, but that only allows rather
> simple partitioning, but no way of sharing and dealing with the per package
> nature of this mechanism.
>
> In the end we decided to expose the allocation bitmaps directly so all
> combinations of the hardware can be utilized.
Note that there are going to be more resources that can be controlled
using the same mechanism (PQR_ASSOC.CLOSID indexes into an
array of resource specific MSRs that specify how much of the resource
is available to the current process). Next one should be along fairly soon.
Keep an eye on chapter 17 in volume 3 of the SDM.
The code changes for this next resource involve new validation functions
(the resource isn't a cache, and the MSRs for it aren't bitmasks). But I think
it extends nicely.
-Tony
Powered by blists - more mailing lists