Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Message-ID: <4cb9aaa1-c4fb-490e-5b91-a05ab1a0e95e@intel.com>
Date:   Thu, 20 Jul 2023 10:27:32 -0700
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101
 Firefox/102.0 Thunderbird/102.13.0
Subject: Re: [PATCH v3 3/8] x86/resctrl: Add a new node-scoped resource to
 rdt_resources_all[]
Content-Language: en-US
To:     "Luck, Tony" <tony.luck@intel.com>
CC:     "Yu, Fenghua" <fenghua.yu@intel.com>,
        Peter Newman <peternewman@google.com>,
        Jonathan Corbet <corbet@lwn.net>,
        Shuah Khan <skhan@linuxfoundation.org>,
        "x86@kernel.org" <x86@kernel.org>,
        Shaopeng Tan <tan.shaopeng@fujitsu.com>,
        James Morse <james.morse@arm.com>,
        Jamie Iles <quic_jiles@quicinc.com>,
        Babu Moger <babu.moger@amd.com>,
        Randy Dunlap <rdunlap@infradead.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        "linux-doc@vger.kernel.org" <linux-doc@vger.kernel.org>,
        "patches@lists.linux.dev" <patches@lists.linux.dev>
References: <20230713163207.219710-1-tony.luck@intel.com>
 <20230713163207.219710-4-tony.luck@intel.com>
 <769521ee-6907-1613-442f-e2915a8ea554@intel.com>
 <ZLcY1MQr5/Ibnv7N@agluck-desk3>
 <076a76c9-ab57-cae2-e6e4-99d26921b578@intel.com>
 <SJ1PR11MB60834DE7D5F7728BF45953F7FC39A@SJ1PR11MB6083.namprd11.prod.outlook.com>
From:   Reinette Chatre <reinette.chatre@intel.com>
In-Reply-To: <SJ1PR11MB60834DE7D5F7728BF45953F7FC39A@SJ1PR11MB6083.namprd11.prod.outlook.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?MTBKdzJCam5UMnFHNlpMUkcveW9NWFZ0cDdMcXh5am5iOXJrYzNSeTh0VGZt?=
 =?utf-8?B?eXkvTDRwaWRBcXRzVDRoa3kwbmhTekI0TmJBNE9uZ0xjWHo0dVpuTTNFU2R4?=
 =?utf-8?B?MW9ydjVpUXk0QUc4Qjh6THVJUmliRGY0TGZ0N3hodnZFZERmVXhiMWZNd2Zr?=
 =?utf-8?B?ZG9SYUYzbFZpcVV3SXhTMzBjV3hOUWRJaEVzS0ZyRHVXcEcwdzdFYzZVa1FN?=
 =?utf-8?B?WFZCVjJFZUdGaE5zN25hMVNpTUwxdEJTRUQvODQ0M1ZrNWwzNmtTMlJLYXNz?=
 =?utf-8?B?Sm16ekRzWmYwUU56OUdJZVJ2ZTRhVXlFSUtCOTZONWs2MjQ0U2FXMVNxKzJi?=
 =?utf-8?B?c3NQR09CTm8rbURYKzZNSUJCQ3ZlcXNqRVNkVzRjQ2hMaGllK3BuL1ZuOGJF?=
 =?utf-8?B?MFlHR0tWOHR6ZEh5L01hOUt5VXBBdUszK2tMN0tkSi9KSUVYZWlmK0FvbVNH?=
 =?utf-8?B?Z01BV2xCT1htbGpTNnhQdXMwek55SjdYOXJuMlUzUEEvaWkwZWhBQTB4WDlu?=
 =?utf-8?B?YnlPelRLdVJTeWx6MSt2M1hsMFNKWEt4RjA0YkNwdjNyNm16R1BsMjByZVRu?=
 =?utf-8?B?Y2dOczlYZ0ZZVGNIcmlXVURmUWpteFBJa2g3ckNmLzFRS29tYmdHSWErM25K?=
 =?utf-8?B?akJKbmw1Yys5OWgzdVFWN0lJK3FabHQ0WjRUTDQ0d0pucmU1QXo4Y0ZDZEJZ?=
 =?utf-8?B?TndNbXVaRXRTYmhkU0J2aFk4V0FacWY0M2hQa0lmeVdDWTU2UkJGQUhFU080?=
 =?utf-8?B?MDhuZWRuMmdaNDNNSnB4V3h4dit5V3htcnRabmtycGpuSmtXN2tlRXRyRWV1?=
 =?utf-8?B?VHdQbmFSV3hXT0w1QzJuUmlTQW95VThYNTJkWjJhTXUydHpZVGJFd2Z2YkhT?=
 =?utf-8?B?WkRPYWtMc3gzL2RWdjRDc3VPWlpHdXZCN3V3WVAvaGJaYm9LZEdWUEk0MkNC?=
 =?utf-8?B?eWF4N1BubTJvaUx2RmRWVG5IeWtVbTc0U3FRR0lSRnJpb25mODRwU0dvaEp5?=
 =?utf-8?B?NVN1YWpiY010YS9aS2syUVlVejBWSndGSUhsRFpoNTA2YStOZmFWNWVIU2J3?=
 =?utf-8?B?SzljTllsNWI0K2tETGsyeHRNOEMwVC9QdnJXbndVaU9BVWg4R0xzOFVWRzNC?=
 =?utf-8?B?ZWpUN1QxZWhnZjhhMmI3K0c1TU5NMVdiTkEvS21HazczQVZOd2ZWU2VNeEJS?=
 =?utf-8?B?T1FUY1lVbFlWa1hHK0NkbWRHckM4eUw0MU11RUhXYlEvZHF3NzB2aytOL2M5?=
 =?utf-8?B?S29OU1NWeWZWS21lQnpLNWMxc3J4WVFrME93ck5TaTFWaU5CZ2ZFeUE0Lzc2?=
 =?utf-8?B?QXhFZ1puYW5KTGJKVEY4SmJ3RFpSRFR2UURjNUhIeXlDcnIwdlZVeWNkVkNQ?=
 =?utf-8?B?TWNvRmozZlpPWURPdU5PWnFJRHhSYW9FS2Y3S3VRUGwyNjh0ZnNKMVNkMnVQ?=
 =?utf-8?B?RVVSYW4xMUlab29nVkY3Z0FJdWxVQUoyTWxaeXJuRjRmcWhQcnkyeFNmNGdY?=
 =?utf-8?B?TGdXQ3hOdTFjUXdiZlUyQ1hHQllGd1ByRHZNVGQ4a3ZJbDFlUkVJajZZN0dq?=
 =?utf-8?B?dDZWZ0hBcDB3WnRMQWRNWDdNdWFEdDI4d2liSXRwVTJJTXQrM2hkMDhCSi8z?=
 =?utf-8?B?dHpSWWk5c1lnaXRHY2lJci9JQ1R6R1dTbEhKZ3NHaWdtakFEVmZXNDQ5Q3Ro?=
 =?utf-8?B?eHIxR0plZXI5UHNSSzJ3bHVlNC9mWUJKZ3U4ZmVKeisvWk9xQk1QM0dqNnJv?=
 =?utf-8?B?MGpna01uZjM2dzF4SVV5Z3YrR2JqdVZSSFJ6S3VIa2dTbFFxZmd6Sjl2Y3Z0?=
 =?utf-8?B?NzhsRFZRcnAxYjJVUi9pQUNZZzNsajRnM3h4SWFENzBWZ0JyZ2FtaU5pSko2?=
 =?utf-8?B?LzROQTNDMUpWQ1NZOEx1Tjc3eGh4V2dYdmxuSEFHeUZvQzArMmNacVFkMmti?=
 =?utf-8?B?eEpDWkk0QWhBQmd1dmtPaHZLeHJxcS9DRTZhYjh2Y2NsQXFScFA2ekhtMUNs?=
 =?utf-8?B?WmJCalVHeEpzK0Rhb2NrU3o0anFTZms0VnovL21BWldLRHgvdU45dEZIVml1?=
 =?utf-8?B?WmZkc0Y2b2FXVm1aYkpEcUp4WTJ1d1JtYTk5a1R4U3VkQXVEQWxFWGlGVysr?=
 =?utf-8?B?T3JPUVo5aHhjZHhkWmNZS2lCK01EYjI5eDBqVW1vRUsvTis4NFZra2tkclZB?=
 =?utf-8?B?K0E9PQ==?=
X-MS-Exchange-CrossTenant-Network-Message-Id: e8b54ed5-16ca-4f48-cee9-08db89469b49
X-MS-Exchange-CrossTenant-AuthSource: SJ2PR11MB7573.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 20 Jul 2023 17:27:35.0716
 (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: CUKOeYfQUzmv9Fjgh4YD1R/X9cT4gRCcUp5WH509MZ4WztS6eapu+2wGiF/tkquLaLKKYlBXb8e6qvDEZRdc52ns8YRU2Imrm5apf+ptsao=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH7PR11MB6499
X-OriginatorOrg: intel.com
X-Spam-Status: No, score=-2.2 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,
        DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,NICE_REPLY_A,
        SPF_HELO_NONE,SPF_NONE,T_SCC_BODY_TEXT_LINE autolearn=ham
        autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on
        lindbergh.monkeyblade.net
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

Hi Tony,

On 7/18/2023 5:11 PM, Luck, Tony wrote:
>> Yes, this is the idea. Thank you for considering it. Something else
>> to consider that may make this even cleaner/simpler would be to review
>> struct rdt_domain and struct rdt_hw_domain members for "monitor" vs "control"
>> usage. These structs could potentially be split further into separate
>> "control" and "monitor" variants. For example, "struct rdt_domain" split into
>> "struct rdt_ctrl_domain" and "struct rdt_mon_domain". If there is a clean
>> split then resctrl can always create two lists with the unnecessary duplication
>> eliminated when two domain lists are created. This would also
>> eliminate the need to scatter ctrl_scope == mon_scope checks throughout.
> 
> You might like what I'm doing in the "resctrl2" re-write[1]. Arch independent code
> that maintains the domain lists for a resource via a cpuhp notifier just has this
> for the domain structure:
> 
> struct resctrl_domain {
>         struct list_head        list;
>         struct cpumask          cpu_mask;
>         int                     id;
>         int                     cache_size;
> };
> 
> Each module managing a resource decides what extra information it wants to
> carry in the domain. So the above structure is common to all, but it is followed
> by whatever the resource module wants. E.g. the CBM masks for each CLOSid
> for the CAT module. The module tells core code the size to allocate.

hmmm ... what I am *hearing* you say is that the goodness from the
rewrite can be added to resctrl? :)

> "cache_size" is only there because the cache topology bits needed to discover
> sizes of caches aren't exported. Both the "size" file and pseudo-locking need
> to know the size.
> 
> It's also possible that you may hate it. There is zero sharing of resource structures
> even if they have the same scope. This is because all modules are independently
> loadable.

Apologies but I am still unable to understand the problem statement that
motivates the rewrite.

Reinette