From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id E850BC433FE for ; Tue, 8 Nov 2022 15:58:19 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234589AbiKHP6S (ORCPT ); Tue, 8 Nov 2022 10:58:18 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:42826 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234310AbiKHP6Q (ORCPT ); Tue, 8 Nov 2022 10:58:16 -0500 Received: from out30-132.freemail.mail.aliyun.com (out30-132.freemail.mail.aliyun.com [115.124.30.132]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id DE8B815701 for ; Tue, 8 Nov 2022 07:58:14 -0800 (PST) X-Alimail-AntiSpam: AC=PASS;BC=-1|-1;BR=01201311R261e4;CH=green;DM=||false|;DS=||;FP=0|-1|-1|-1|0|-1|-1|-1;HT=ay29a033018045168;MF=shawnwang@linux.alibaba.com;NM=1;PH=DS;RN=21;SR=0;TI=SMTPD_---0VUK61dP_1667923078; Received: from 30.39.65.162(mailfrom:shawnwang@linux.alibaba.com fp:SMTPD_---0VUK61dP_1667923078) by smtp.aliyun-inc.com; Tue, 08 Nov 2022 23:58:09 +0800 Message-ID: Date: Tue, 8 Nov 2022 23:57:57 +0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0) Gecko/20100101 Thunderbird/102.4.1 From: Shawn Wang Subject: Re: [PATCH 06/18] x86/resctrl: Allow the allocator to check if a CLOSID can allocate clean RMID To: James Morse , x86@kernel.org, linux-kernel@vger.kernel.org Cc: Fenghua Yu , Reinette Chatre , Thomas Gleixner , Ingo Molnar , Borislav Petkov , H Peter Anvin , Babu Moger , shameerali.kolothum.thodi@huawei.com, D Scott Phillips OS , carl@os.amperecomputing.com, lcherian@marvell.com, bobo.shaobowang@huawei.com, tan.shaopeng@fujitsu.com, Jamie Iles , Xin Hao , xingxin.hx@openanolis.org, baolin.wang@linux.alibaba.com, peternewman@google.com References: <20221021131204.5581-1-james.morse@arm.com> <20221021131204.5581-7-james.morse@arm.com> In-Reply-To: <20221021131204.5581-7-james.morse@arm.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi James, On 10/21/2022 9:11 PM, James Morse wrote: > MPAM's PMG bits extend its PARTID space, meaning the same PMG value can be > used for different control groups. > > This means once a CLOSID is allocated, all its monitoring ids may still be > dirty, and held in limbo. > > Add a helper to allow the CLOSID allocator to check if a CLOSID has dirty > RMID values. This behaviour is enabled by a kconfig option selected by > the architecture, which avoids a pointless search for x86. > > Signed-off-by: James Morse > --- > arch/x86/kernel/cpu/resctrl/internal.h | 1 + > arch/x86/kernel/cpu/resctrl/monitor.c | 31 ++++++++++++++++++++++++++ > arch/x86/kernel/cpu/resctrl/rdtgroup.c | 18 +++++++++------ > 3 files changed, 43 insertions(+), 7 deletions(-) > +/** > + * resctrl_closid_is_dirty - Determine if clean RMID can be allocate for this > + * CLOSID. > + * @closid: The CLOSID that is being queried. > + * > + * MPAM's equivalent of RMID are per-CLOSID, meaning a freshly allocate CLOSID > + * may not be able to allocate clean RMID. To avoid this the allocator will > + * only return clean CLOSID. > + */ > +bool resctrl_closid_is_dirty(u32 closid) > +{ > + struct rmid_entry *entry; > + int i; > + > + lockdep_assert_held(&rdtgroup_mutex); > + > + if (IS_ENABLED(CONFIG_RESCTRL_RMID_DEPENDS_ON_CLOSID)) > + return false; Since dirty closid occurs when the kconfig option for MPAM is enabled, it seems that the condition of the if statement here should take the opposite value: if (!IS_ENABLED(CONFIG_RESCTRL_RMID_DEPENDS_ON_CLOSID)) > + > + for (i = 0; i < resctrl_arch_system_num_rmid_idx(); i++) { > + entry = &rmid_ptrs[i]; > + if (entry->closid != closid) > + continue; > + > + if (entry->busy) > + return true; > + } > + > + return false; > +} > + Shawn