[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <pve5jzaocwr6okpekrmtqut7gza2yeij4lbkweelk4ei7yxwvx@qrsqfhaebuza>
Date: Mon, 9 Oct 2023 08:44:40 +0200
From: Maciej Wieczór-Retman
<maciej.wieczor-retman@...el.com>
To: Reinette Chatre <reinette.chatre@...el.com>
CC: <fenghua.yu@...el.com>, <tglx@...utronix.de>, <mingo@...hat.com>,
<bp@...en8.de>, <dave.hansen@...ux.intel.com>, <corbet@....net>,
<x86@...nel.org>, <hpa@...or.com>, <linux-kernel@...r.kernel.org>,
<linux-doc@...r.kernel.org>, <ilpo.jarvinen@...ux.intel.com>,
<bmoger@....com>
Subject: Re: [PATCH v4 0/4] x86/resctrl: Non-contiguous bitmasks in Intel CAT
On 2023-10-06 at 10:53:52 -0700, Reinette Chatre wrote:
>Hi Maciej,
>
>On 10/5/2023 1:14 AM, Maciej Wieczor-Retman wrote:
>> Until recently Intel CPUs didn't support using non-contiguous 1s
>> in Cache Allocation Technology (CAT). Writing a bitmask with
>> non-contiguous 1s to the resctrl schemata file would fail.
>>
>> Intel CPUs that support non-contiguous 1s can be identified through a
>> CPUID leaf mentioned in the "Intel® 64 and IA-32 Architectures
>> Software Developer’s Manual" document available at:
>> https://www.intel.com/content/www/us/en/developer/articles/technical/intel-sdm.html
>>
>> Add kernel support for detecting if non-contiguous 1s in Cache
>> Allocation Technology (CAT) are supported by the hardware. Also add a
>> new resctrl FS file to output this information to the userspace.
>> Keep the hardcoded value for Haswell CPUs only since they do not have
>> CPUID enumeration support for Cache allocation.
>>
>> Since the selftests/resctrl files are going through many rewrites and
>> cleanups the appropriate selftest is still a work in progress. For
>> basic selftesting capabilities use the bash script attached below this
>> paragraph. It checks whether various bitmasks written into resctrl FS
>> generate output consistent with reported feature support.
>
>This work conflicts with Babu's series [1] that is also ready for inclusion.
>We could wait for outcome of next level review to determine who will need
>to rebase. It may help to provide a snippet of the conflict resolution
>in anticipation of Babu's series being merged first (I will propose exactly
>the same to Babu for the scenario of this work merged first).
>
>Reinette
>
>[1] https://lore.kernel.org/lkml/20231003235430.1231238-1-babu.moger@amd.com/
Thanks for fiding this issue. I can see how to resolve the conflict but
where can I put the solution?
I'm guessing in the cover letter?
I'm going to resend the series very soon to apply Babu's comment and
tags. I'll then attach the snippet you mentioned wherever you think it
would fit best.
--
Kind regards
Maciej Wieczór-Retman
Powered by blists - more mailing lists