Received-SPF: pass (google.com: domain of linux-kernel+bounces-141410-linux.lists.archive=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) client-ip=139.178.88.99;
Message-ID: <4bc84ef2-6db4-4d3b-9b48-42396e78356c@intel.com>
Date: Thu, 11 Apr 2024 10:35:56 -0700
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v1 01/31] x86/resctrl: Fix allocation of cleanest CLOSID
 on platforms with no monitors
To: Dave Martin <Dave.Martin@arm.com>, David Hildenbrand <david@redhat.com>
CC: James Morse <james.morse@arm.com>, <x86@kernel.org>,
	<linux-kernel@vger.kernel.org>, Fenghua Yu <fenghua.yu@intel.com>, "Thomas
 Gleixner" <tglx@linutronix.de>, Ingo Molnar <mingo@redhat.com>, "Borislav
 Petkov" <bp@alien8.de>, H Peter Anvin <hpa@zytor.com>, Babu Moger
	<Babu.Moger@amd.com>, <shameerali.kolothum.thodi@huawei.com>, "D Scott
 Phillips OS" <scott@os.amperecomputing.com>, <carl@os.amperecomputing.com>,
	<lcherian@marvell.com>, <bobo.shaobowang@huawei.com>,
	<tan.shaopeng@fujitsu.com>, <baolin.wang@linux.alibaba.com>, Jamie Iles
	<quic_jiles@quicinc.com>, Xin Hao <xhao@linux.alibaba.com>,
	<peternewman@google.com>, <dfustini@baylibre.com>, <amitsinght@marvell.com>,
	Rex Nie <rex.nie@jaguarmicro.com>
References: <20240321165106.31602-1-james.morse@arm.com>
 <20240321165106.31602-2-james.morse@arm.com>
 <1e19965c-51f2-4f7a-8d29-e40f4e54a72c@redhat.com>
 <ZhfwEF5EJiTM5Hjm@e133380.arm.com>
Content-Language: en-US
From: Reinette Chatre <reinette.chatre@intel.com>
In-Reply-To: <ZhfwEF5EJiTM5Hjm@e133380.arm.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: bulk
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?eEtIT3ZBTEpXUmQzN250UmNiN1FPZzZuREZncmg2RWlDd0ErMnJwWmYxZ1JX?=
 =?utf-8?B?OEZIY1dXV3JENXNncFJmRW9McjUyTklDRW9QdklmVDlqOWkzSmE0YjV3WWJ5?=
 =?utf-8?B?V0o0dEhHck53eUwvbG5xZlYyVTJjczlUV0tvMlZobThCMzAyaFFVbTJrd3Fk?=
 =?utf-8?B?UzBmcnpSbVB2WUFjTzRWNDdUTkYwR1NLdVdTV1lRdVhNUHBnQ2tzZ045VmM1?=
 =?utf-8?B?NkY3ZVJwU3M0cmFucVNZRWhlQU5Ka2lKKzdIZ1VVekdsdzhTZnR2MTkvb0lM?=
 =?utf-8?B?L0dMaFFBWUNScXM3UTJSOXZscUlySzRCanRGM2UxMEJUOHMweDYzRnQ4dTdx?=
 =?utf-8?B?QTBxcUtnZFVBOG5CUlBBTWw5WFkyd1BSNllONEoyN2JzNVZqUFBlZkxKcVdi?=
 =?utf-8?B?Njk1SzZ0RWsyMStoSWgrWlo3ZmFyK0NvUE9SMlN3NXlpQjdlYmdqNEIybWlE?=
 =?utf-8?B?ZkJBS0hGUWNKUnVKTFRyVlRjMHJnQXYwb3dIa1BwQ0ZkclNhRUhnTjk4ME5m?=
 =?utf-8?B?YTNKb3ZwaGZSWVZ6dU5hT2hzQWVKOTRDWGVlZkJzTVcxeHBkSXQwb0lGRVVs?=
 =?utf-8?B?UlI2M0d6VlAwc2hkOE05dlhtVkppRktIN3NCWUVRRmZVNU9lcGI3dzNoaHNK?=
 =?utf-8?B?SVdaOUhkY2JtNGVLZE9UUCt6ZEtlRjV1bVJBVk41RUJLZDZrME81K29sVzVU?=
 =?utf-8?B?ckNtMmtYUkFnaWFXYkxDTUtTTElpeUdHV3I5VlU2Y0VzUTlXcWpKT1Nad3Jh?=
 =?utf-8?B?ZzhmV000bVNNMkNpOWFUU0pkNURkMVRpa2VLNW9aWk5WdlAwTUZSaWRCVHEy?=
 =?utf-8?B?RmhuazQ2a2VyRnlDL0x2b1Zha0ZicEQzbHpXZHliQ3Q1bU80YlBHSkl1MDNz?=
 =?utf-8?B?bXB4ZlUrRnlWbmFRV21PWFdFQWFqeFJmOEdscEhtM0xydjRCYU1keXNIdklZ?=
 =?utf-8?B?S3YvME9XWENCQUV0SkQ0cmVhS0g5K1ZIcnh3ZXpNKytBc2FxUzlOVE9DdXZa?=
 =?utf-8?B?UzhjMmNDNi9tdFFVclliMXJMQUNnYWhQS3YrQWtFZWk1YmpEYlZqTFg1bEVm?=
 =?utf-8?B?SXJ3VmZBc3p6eWlQQmpRQWhJbityOWhpbHQzU0s0R0JTczVHdHdUeEdjU0Yx?=
 =?utf-8?B?b2ZPUitiSCtOd3JRcHZ3WVVvQTkwN1FNUU9JbUJQeHBFTGZRQ2Y1eG1ZL0Zj?=
 =?utf-8?B?VERCcGNoRmFEc3FDd2xRVkRkTDZ4VzFOMmVpU01FclpSVDUxcStINDVxLytz?=
 =?utf-8?B?aFNFblQ3bS8vbUNTVHppbWZSRHp6M0JNRStLOEpiMDQ0ZU53bjhXY20zVXM5?=
 =?utf-8?B?RytVaDNPckVaVE93WWhFOW55YU1UK0p6TzRHY3plSFUrOW13dmhEcUE5SVdu?=
 =?utf-8?B?cVk5RWlZd0FaUVdzVTBpRE53YjJpN3dBRmUrb0ExbUpPUnNqUndyVGI5MDBy?=
 =?utf-8?B?Qk5KVTJ5cHBlcUNWR2dxalBZNVdmQUE1Qm1TV2prT29MSWhiNGplN1J0bzFT?=
 =?utf-8?B?R2RmSlhBQWtLRGlTeUJkMEt3UnFWV0FKQ2xkZ2UvNkhYNlVBTndRaTBrd2du?=
 =?utf-8?B?M0VKTXRaQWtxRW5oMWYxTDJ6SXhTZFg3aGFGM1QxbTA2eGk0THdyR2pzVkxi?=
 =?utf-8?B?L05TUlh2emJGYnJWWDYrN0lMalkxRmVJRGQ1RC9nOWl3cmNnbGtsUDlwcUxl?=
 =?utf-8?B?cVVaVkV6blhtQlhLaHBXTWpTOE5IckV3OGpSWlNobzJXcUpPVEZFZTl3dnBj?=
 =?utf-8?B?L3JnVEd6akZLMm5jcTBhOTAxSm5vU0xYcExvV0ZkUXU2Z0VpUVBuV1VFdnBN?=
 =?utf-8?B?azNVb2xicFZhZ2hJaFhURy9MbXhBUTlxMTRMbGJ4WFhpd29oQkE5THAyU25n?=
 =?utf-8?B?UytDRWJxVU1ldWxRT21qbWhGUHpwNmFBUnVacFhXaHhzK3hqS1RQVTBHVUJM?=
 =?utf-8?B?bjEvNEJGbFlKZDNWdGE1V1VIcEFLUjVaN2FDK2xNOHRUQzFNQThramU5cXB5?=
 =?utf-8?B?eGQrMnNReHI2MzdiRVBQRHpzMzNsWm4zM0k3NVBka1JSY3pVSkQvc3dUUkpq?=
 =?utf-8?B?aW9HV1lRTkRxSmZhbGM5YkNiY2VIR0R0ZG42WjRJUm1Ncm1HV3luZitDNXBp?=
 =?utf-8?B?MDF6WnVlZmNLTEx2Wi80QkVlMlJiQ01XekFkZWErUU5ETE41eUFVZkI4MGVN?=
 =?utf-8?B?amc9PQ==?=
X-MS-Exchange-CrossTenant-Network-Message-Id: 043ef3e6-b814-4872-0870-08dc5a4dd9de
X-MS-Exchange-CrossTenant-AuthSource: SJ2PR11MB7573.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 11 Apr 2024 17:35:59.5597
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 46c98d88-e344-4ed4-8496-4ed7712e255d
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: bUXxyIl1/UFRe8r17/lLloCYkDSWdWCYxzXqOgnj+L9lPuP1MXUYfVtJXSeoBMl5CDBuXI+zaBs0vP6KMBdULC/E2GubwE5bOeLc44K4dsE=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH0PR11MB5112
X-OriginatorOrg: intel.com

Hi Dave,

On 4/11/2024 7:13 AM, Dave Martin wrote:
> On Tue, Apr 09, 2024 at 10:05:33AM +0200, David Hildenbrand wrote:
>> On 21.03.24 17:50, James Morse wrote:
>>> commit 6eac36bb9eb0 ("x86/resctrl: Allocate the cleanest CLOSID by
>>> searching closid_num_dirty_rmid") added a Kconfig option that causes
>>> resctrl to search for the CLOSID with the fewest dirty cache lines when
>>> creating a new control group. This depends on the values read from the
>>> llc_occupancy counters.
> 
> [...]
> 
>> It's weird to not see RESCTRL_RMID_DEPENDS_ON_CLOSID appear in any Kconfig file.
>> I guess it will all make sense once the refactoring is done :)
> 
> Agreed; a stub Kconfig item could be added, but since the file layout
> and naming conventions change after this patch, doing this would
> probably just create noise in the series though.
> 
> Looking at <linux/kconfig.h> (yikes!), IS_ENABLED() is designed to do
> the right thing for non-existing Kconfigs...
> 
> If nobody is too concerned about the temporarily dangling IS_ENABLED()s
> in this series, I won't propose any change here.

I am not concerned about this. Please note that these IS_ENABLED() checks
are not introduced in this series, they were introduced in the previous
portion of this MPAM work that can be found in upstream resctrl.

Reinette