Re: [RFC PATCH 00/20] Intel(R) Resource Director Technology Cache Pseudo-Locking enabling

[Reinette Chatre <reinette.chatre@intel.com>]

Hi Thomas,

On 1/16/2018 3:38 AM, Thomas Gleixner wrote:
> On Mon, 15 Jan 2018, Hindman, Gavin wrote:
>>> From: linux-kernel-owner@vger.kernel.org [mailto:linux-kernel-
>>> owner@vger.kernel.org] On Behalf Of Thomas Gleixner
>>> On Fri, 17 Nov 2017, Reinette Chatre wrote:
>>>>
>>>> 1) PALLOC is not upstream and while inquiring about the status of this
>>>> work (please see https://github.com/heechul/palloc/issues/4 for
>>>> details) we learned that one reason for this is that recent Intel
>>>> processors are not well supported.
>>>
>>> So if I understand Heechul correctly then recent CPUs cannot be supported
>>> easily due to changes in the memory controllers and the cache. I assume the
>>> latter is related to CAT.
> 
> Is that assumption correct?

>From what I understand to be able to allocate memory from a specific
DRAM bank or cache set PALLOC requires knowing exactly which DRAM bank
or cache set a physical address maps to. The PALLOC implementation
relies on user space code that times a variety of memory accesses to
guess which bits determine DRAM bank or cache set placement. These bits
are then provided to the kernel implementation as the page coloring input.

The comments at https://github.com/heechul/palloc/issues/4 point out
that it is this user space guessing of physical address to specific DRAM
bank and cache set mapping that is harder in recent Intel processors.
This is not related to CAT. CAT could be used to limit the number of
ways to which the contents of a physical address can be allocated, CAT
does not modify the set to which the physical address maps.

Without possibility of using PALLOC I do not currently know how to
answer your request for a comparison with a cache coloring mechanism. I
will surely ask around and do more research.

Reinette