From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) (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 4FB0B2D8782 for ; Tue, 6 Jan 2026 14:37:58 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=185.176.79.56 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1767710279; cv=none; b=aCYrQunYdaZ631+LckgDVKdEcwhABDeVXSD+I7fxV/ejeuBnKTnRzjTI8yiiLN0akSYAGv42Bsg3HoJ+OmVF7qxsVnjEA1aMrDcgHZoeXzR0MmOogCYVYNt+1gV4P1u+EHf8cRiWI4T6jLny8Fwwl4czPTwtdJQQ2Qukj25LtMY= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1767710279; c=relaxed/simple; bh=ZIpw7DGuumGa1FD7GXVFkr+3tTtl45NsJhEhEzPwX6Y=; h=Date:From:To:CC:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=IPSJh3fCsb9L7etMqAZ8PbjZ89KkhLUU196C31PT33B/DrqkWEWuaJ+4wRhBSTGWfDMbIiVEoSCy/uzyZrxW3aMlbSl+dTKHJiF9gVgHE2Z6x/JF09wv6mc17WBCA9LqpwiN90DKzRk81FIH61qPp1tX8XWRfYZ/X1WCC4d0Bgg= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=huawei.com; spf=pass smtp.mailfrom=huawei.com; arc=none smtp.client-ip=185.176.79.56 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=huawei.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=huawei.com Received: from mail.maildlp.com (unknown [172.18.224.107]) by frasgout.his.huawei.com (SkyGuard) with ESMTPS id 4dlv0L0LzDzJ46fN; Tue, 6 Jan 2026 22:37:54 +0800 (CST) Received: from dubpeml100005.china.huawei.com (unknown [7.214.146.113]) by mail.maildlp.com (Postfix) with ESMTPS id B743E4057F; Tue, 6 Jan 2026 22:37:55 +0800 (CST) Received: from localhost (10.195.245.156) by dubpeml100005.china.huawei.com (7.214.146.113) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1544.36; Tue, 6 Jan 2026 14:37:54 +0000 Date: Tue, 6 Jan 2026 14:37:52 +0000 From: Jonathan Cameron To: Ben Horgan CC: , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , Subject: Re: [PATCH v2 33/45] arm_mpam: resctrl: Allow resctrl to allocate monitors Message-ID: <20260106143752.00000600@huawei.com> In-Reply-To: <20251219181147.3404071-34-ben.horgan@arm.com> References: <20251219181147.3404071-1-ben.horgan@arm.com> <20251219181147.3404071-34-ben.horgan@arm.com> X-Mailer: Claws Mail 4.3.0 (GTK 3.24.42; x86_64-w64-mingw32) 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="US-ASCII" Content-Transfer-Encoding: 7bit X-ClientProxiedBy: lhrpeml100010.china.huawei.com (7.191.174.197) To dubpeml100005.china.huawei.com (7.214.146.113) On Fri, 19 Dec 2025 18:11:35 +0000 Ben Horgan wrote: > From: James Morse > > When resctrl wants to read a domain's 'QOS_L3_OCCUP', it needs to allocate > a monitor on the corresponding resource. Monitors are allocated by class > instead of component. > > MBM monitors are much more complicated, if there are enough monitors, they > will be pre-allocated and free-running. If ABMC is in use instead then > 'some' are pre-allocated in a different way, and need assigning. > > Add helpers to allocate a CSU monitor. These helper return an out of range > value for MBM counters. > > Allocating a montitor context is expected to block until hardware resources monitor > become available. This only makes sense for QOS_L3_OCCUP as unallocated MBM > counters are losing data. > > Signed-off-by: James Morse > Signed-off-by: Ben Horgan > --- > Changes since rfc: > USE_RMID_IDX -> USE_PRE_ALLOCATED in comment > Remove unnecessary arch_mon_ctx = NULL As with some other patches, I'm not taking the time at this point to dig into all the interactions with resctl as others will cover that much better than me. Too much to get done :( With that in mind. Reviewed-by: Jonathan Cameron J