Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751459AbeAQAxI (ORCPT + 1 other); Tue, 16 Jan 2018 19:53:08 -0500 Received: from mga09.intel.com ([134.134.136.24]:11973 "EHLO mga09.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750750AbeAQAxH (ORCPT ); Tue, 16 Jan 2018 19:53:07 -0500 X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.46,369,1511856000"; d="scan'208";a="11118170" Subject: Re: [RFC PATCH 00/20] Intel(R) Resource Director Technology Cache Pseudo-Locking enabling To: Thomas Gleixner , "Hindman, Gavin" Cc: "Yu, Fenghua" , "Luck, Tony" , "vikas.shivappa@linux.intel.com" , "Hansen, Dave" , "mingo@redhat.com" , "hpa@zytor.com" , "x86@kernel.org" , "linux-kernel@vger.kernel.org" References: <93415e33-6adf-047f-9a46-0862c3cd33b6@intel.com> From: Reinette Chatre Message-ID: <182fb032-9286-f3ea-c273-1a41d7934651@intel.com> Date: Tue, 16 Jan 2018 16:53:06 -0800 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Return-Path: 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