From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from out30-119.freemail.mail.aliyun.com (out30-119.freemail.mail.aliyun.com [115.124.30.119]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id E36D4378D9C for ; Fri, 5 Jun 2026 10:06:46 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=115.124.30.119 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780654009; cv=none; b=ct1U15ZNQ6s1bJRL1jTlJe2T9ZdI9/iDIP3Gn4DlkeeYDGLSRCcNTf7ze4uYElvkZ0MqWPePFvdUE+D2dh5JAzWCB/WC6gFF4DHchcmR2uc3RPAq+JqLvcVqrZBHY/hcJB7pkXS5ygQ678K5L5ZkDkU0/OuVVe4fyN1DhIycAp0= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780654009; c=relaxed/simple; bh=9H3ryXV0D1sOeG6fVAIQOA55dyz76muo3KfTM+VCC1g=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=Coo+FHo6Epg1ujOIzlSIOGhstahbNRIZbKZy4G+4ROkMEjqN7MC/0kmcjZmLaGlhaTcxLqHXgkK3Vi0TKsJyYG/c2cKfDWt86HwbZjUPo6X37ozTNMSs/57sF3Wxk9NBHJklGDcA5+HSQNkbXspxwljPdJm8+mji3PyfHBCNAlU= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.alibaba.com; spf=pass smtp.mailfrom=linux.alibaba.com; dkim=pass (1024-bit key) header.d=linux.alibaba.com header.i=@linux.alibaba.com header.b=Ou9y5Q35; arc=none smtp.client-ip=115.124.30.119 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.alibaba.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.alibaba.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux.alibaba.com header.i=@linux.alibaba.com header.b="Ou9y5Q35" DKIM-Signature:v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.alibaba.com; s=default; t=1780654004; h=From:To:Subject:Date:Message-ID:MIME-Version:Content-Type; bh=Qu2bMv4v+N2SGLxeVAI93JvupJdyNVdiES0bGz8O/uo=; b=Ou9y5Q35uceKKQeiYUF/OGj+uAzusMCbV3gUKQQLzi7SKygoqxOSoq+JccGxlpWv7j9tp8qtOs36+Zk5FLyL3ubm84K86x+ajIE/zyk2M73EX2NUjlXySp0ueOK8mpsiG2vu3PQ26mFyM1XONMprxiA9838bAqoICDsJKqlaYOw= X-Alimail-AntiSpam:AC=PASS;BC=-1|-1;BR=01201311R181e4;CH=green;DM=||false|;DS=||;FP=0|-1|-1|-1|0|-1|-1|-1;HT=maildocker-contentspam033032089153;MF=qinyuntan@linux.alibaba.com;NM=1;PH=DS;RN=14;SR=0;TI=SMTPD_---0X4D-kFe_1780654002; Received: from banye.tbsite.net(mailfrom:qinyuntan@linux.alibaba.com fp:SMTPD_---0X4D-kFe_1780654002 cluster:ay36) by smtp.aliyun-inc.com; Fri, 05 Jun 2026 18:06:43 +0800 From: Qinyun Tan To: qinyuntan@linux.alibaba.com, "Moger, Babu" Cc: "Luck, Tony" , Babu Moger , Reinette Chatre , corbet@lwn.net, Dave.Martin@arm.com, james.morse@arm.com, tglx@kernel.org, bp@alien8.de, dave.hansen@linux.intel.com, x86@kernel.org, feng.tang@linux.alibaba.com, linux-kernel@vger.kernel.org Subject: Re: [PATCH v3 04/12] x86,fs/resctrl: Program PLZA through kmode arch hooks Date: Fri, 5 Jun 2026 18:06:42 +0800 Message-ID: <20260605100642.1103628-1-qinyuntan@linux.alibaba.com> X-Mailer: git-send-email 2.43.7 In-Reply-To: References: <0cfd813e10072eefc8f4d84328e83bd9a6220ad4.1777591497.git.babu.moger@amd.com> <1a410ca9-f4a2-4956-8477-033d61a733be@amd.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On Wed, May 20, 2026 at 06:09:27PM -0500, Moger, Babu wrote: > On 5/20/2026 5:16 PM, Luck, Tony wrote: > > So maybe I'm just confused by the name > > "global_assign_ctrl_inherit_mon_per_cpu" > > > > That sounds like "Use the CLOSID from PLZA, but keep the RMID from > > legacy PQR_ASSOC. > > > To make that happen, I thing the PLZA MSR should have rmid_en = 0. > > But the only code I see that sets this always sets rmid_en=1. > > Setting rmid_en = 0 in [1] disables counting of kernel usage for > RMID 1 (from ctrl1). I've been reviewing these patches and went back to the AMD hardware manual (Publication #69193, Rev 1.00, March 2026) to understand the RMID_EN semantics. The spec defines RMID_EN (bit 31 of PQR_PLZA_ASSOC, MSR C000_03FCh): "RMID_EN (PLZA Resource Monitoring Identifier Association Enable) - bit 31. When set and PLZA_EN is set, the Resource Monitoring Identifier (RMID) for this logical processor executing at CPL=0 is specified in the RMID field instead of PQR_ASSOC[RMID]." Reading "instead of PQR_ASSOC[RMID]", my understanding is that when RMID_EN is clear, the hardware falls back to PQR_ASSOC[RMID] - the user process's RMID - rather than disabling monitoring entirely. If that reading is correct, RMID_EN would be a source selector between PLZA and PQR_ASSOC, not an on/off switch for counting. Babu, could you confirm whether that is the intended hardware behavior? > The key difference between the two modes is: > > In one mode, user and kernel usage are counted together. > In the other mode, kernel usage is counted separately from user usage. If RMID_EN=0 does fall back to PQR_ASSOC[RMID], then the "counted together" behavior only holds when the user process happens to be in the same group as the PLZA-bound group. Taking Tony's example: # mkdir ctrl1 # CLOSID=1, RMID=1, bound to inherit_mon via PLZA # mkdir ctrl2 # CLOSID=2, RMID=2 # echo $$ > ctrl2/tasks With rmid_en=1 (current code): when the shell (in ctrl2, PQR_ASSOC RMID=2) enters kernel mode, kernel activity is counted under PLZA RMID=1. The user process's RMID is NOT inherited. With rmid_en=0: kernel mode would fall back to PQR_ASSOC RMID=2, correctly inheriting the monitoring identity of the current user process - which seems to be what "inherit_mon" intends. If this reading is right, Tony's suggestion of adding a parameter to control rmid_en based on the mode would be the right fix: void resctrl_arch_configure_kmode(const struct cpumask *cpu_mask, u32 closid, u32 rmid, bool assign_rmid, bool enable) where assign_rmid=true sets RMID_EN=1 (assign_mon) and assign_rmid=false sets RMID_EN=0 (inherit_mon). --- Separately, I have a question about the group type constraint for global_assign_ctrl_assign_mon_per_cpu (assign_mon mode). In patch 08/12 ("fs/resctrl: Make info/kernel_mode writable and identify the bound group"), resctrl_kernel_mode_write() enforces that assign_mon must bind to an RDTMON_GROUP: if (kmode == BIT(GLOBAL_ASSIGN_CTRL_ASSIGN_MON_PER_CPU) && rdtgrp->type != RDTMON_GROUP) { This forces the user to create a ctrl group plus a monitor sub-group. But since the kernel-mode group is dedicated to kernel work and no user tasks are assigned to it, the ctrl group's own RMID (allocated via alloc_rmid() at mkdir time) should be clean and usable. Requiring an extra monitor group seems to waste a scarce RMID. Would it make sense to relax this constraint so that assign_mon also accepts an RDTCTRL_GROUP? The path infrastructure (rdtgroup_by_kmode_path and resctrl_kernel_mode_show) already handles the "//" form, so only the check above would need to change: mkdir /sys/fs/resctrl/kernel_ctrl echo "global_assign_ctrl_assign_mon_per_cpu:group=kernel_ctrl//" \ > info/kernel_mode Thanks, Qinyun