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 bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 469FDCDC18E for ; Tue, 6 Jan 2026 12:20:06 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:List-Subscribe:List-Help :List-Post:List-Archive:List-Unsubscribe:List-Id:Content-Transfer-Encoding: Content-Type:MIME-Version:References:In-Reply-To:Message-ID:Subject:CC:To: From:Date:Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=5EtEdiow1kF21Deszkjq7KrV6ShuDCebRb8GXYCOhjY=; b=Cb6T8gvfoJ61PT2eHTUulw4fLD KTGalHL++YVW74snvKN3VCfVnqvU5m+z6B0w25HsWRPV1ISVQyKLvqWeVq5HFIQ4AYSu3/x4fhlFj kz2avhJZTbGQjuZaexewcyc5l5zmKb9/S2KhekLeX/KWDW6OkA9ZyOQm2JXBRTErP9B5JJVf7N4hw ZvMcuqNgu0nsl3/VO85DtXXPDoIpeMFpJuMQNdkyR42gqqzOgAqoYKy66xo0PiClMBNMYpbFFUXSy wPcVbcOVQbWStwPAcdhppREm4U2uGx3UpTMFvKr+lD2Jacm0002CAs9DvZ4Y7RoHvw+QJd43x9+gW x9zUDbDQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.98.2 #2 (Red Hat Linux)) id 1vd62a-0000000Cyv8-1yOO; Tue, 06 Jan 2026 12:20:00 +0000 Received: from frasgout.his.huawei.com ([185.176.79.56]) by bombadil.infradead.org with esmtps (Exim 4.98.2 #2 (Red Hat Linux)) id 1vd62X-0000000Cyum-0Nn5 for linux-arm-kernel@lists.infradead.org; Tue, 06 Jan 2026 12:19:58 +0000 Received: from mail.maildlp.com (unknown [172.18.224.107]) by frasgout.his.huawei.com (SkyGuard) with ESMTPS id 4dlqwx5Qw4zJ4678; Tue, 6 Jan 2026 20:19:45 +0800 (CST) Received: from dubpeml100005.china.huawei.com (unknown [7.214.146.113]) by mail.maildlp.com (Postfix) with ESMTPS id 491D240570; Tue, 6 Jan 2026 20:19:47 +0800 (CST) Received: from localhost (10.48.155.65) 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 12:19:45 +0000 Date: Tue, 6 Jan 2026 12:19:44 +0000 From: Jonathan Cameron To: Ben Horgan CC: , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , Zeng Heng Subject: Re: [PATCH v2 25/45] arm_mpam: resctrl: Add support for 'MB' resource Message-ID: <20260106121944.0000499e@huawei.com> In-Reply-To: <20251219181147.3404071-26-ben.horgan@arm.com> References: <20251219181147.3404071-1-ben.horgan@arm.com> <20251219181147.3404071-26-ben.horgan@arm.com> X-Mailer: Claws Mail 4.3.0 (GTK 3.24.42; x86_64-w64-mingw32) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Originating-IP: [10.48.155.65] X-ClientProxiedBy: lhrpeml500012.china.huawei.com (7.191.174.4) To dubpeml100005.china.huawei.com (7.214.146.113) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20260106_041957_444450_8D0D2E5B X-CRM114-Status: GOOD ( 34.97 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Fri, 19 Dec 2025 18:11:27 +0000 Ben Horgan wrote: > From: James Morse > > resctrl supports 'MB', as a percentage throttling of traffic somewhere > after the L3. This is the control that mba_sc uses, so ideally the class > chosen should be as close as possible to the counters used for mba_local. > > MB's percentage control should be backed either with the fixed point either's "or" is missing. (sentence should include the second choice) > fraction MBW_MAX. The bandwidth portion bitmaps is not used as its tricky > to pick which bits to use to avoid contention, and may be possible to > expose this as something other than a percentage in the future. > > CC: Zeng Heng > Co-developed-by: Dave Martin > Signed-off-by: Dave Martin > Signed-off-by: James Morse > > Signed-off-by: Ben Horgan As mentioned in earlier review I'd like an overview doc of the heuristics used to map to the resctrl everything is a xeon view of the world. At least some of our platforms are far enough from this view that the heuristics fail (others can provide more info on that than I can). That's fine as I'd rather not squash something inappropriate into a viewpoint that doesn't fit. Better to leave those for later solutions! Otherwise, just minor comments inline. Jonathan > --- > drivers/resctrl/mpam_resctrl.c | 212 ++++++++++++++++++++++++++++++++- > 1 file changed, 211 insertions(+), 1 deletion(-) > > diff --git a/drivers/resctrl/mpam_resctrl.c b/drivers/resctrl/mpam_resctrl.c > index a20656e49edc..e376841c5596 100644 > --- a/drivers/resctrl/mpam_resctrl.c > +++ b/drivers/resctrl/mpam_resctrl.c ... > +static u32 get_mba_min(struct mpam_props *cprops) > +{ > + u32 val = 0; > + > + if (mba_class_use_mbw_max(cprops)) > + val = mbw_max_to_percent(val, cprops); > + else > + WARN_ON_ONCE(1); > + > + return val; I'd be tempted to handle the error case first to make clear this is really just a sanity checking wrapper around the max_to_percent() function. if (!mba_class_use_mbw_max(cprops)) { WARN_ON_ONCE(1); return 0; } return mbw_max_to_percent(val, cprops); > +} > +/* > + * topology_matches_l3() - Is the provided class the same shape as L3 > + * @victim: The class we'd like to pretend is L3. > + * > + * resctrl expects all the world's a Xeon, and all counters are on the > + * L3. We play fast and loose with this, mapping counters on other > + * classes - provided the CPU->domain mapping is the same kind of shape. > + * > + * Using cacheinfo directly would make this work even if resctrl can't > + * use the L3 - but cacheinfo can't tell us anything about offline CPUs. > + * Using the L3 resctrl domain list also depends on CPUs being online. > + * Using the mpam_class we picked for L3 so we can use its domain list > + * assumes that there are MPAM controls on the L3. > + * Instead, this path eventually uses the mpam_get_cpumask_from_cache_id() > + * helper which can tell us about offline CPUs ... but getting the cache_id > + * to start with relies on at least one CPU per L3 cache being online at > + * boot. So the usual mess of maxcpus=1 breaks it for anything other than first L3? I'm not entirely against that but it may be a little unexpected. > + * > + * Walk the victim component list and compare the affinity mask with the > + * corresponding L3. The topology matches if each victim:component's affinity > + * mask is the same as the CPU's corresponding L3's. These lists/masks are > + * computed from firmware tables so don't change at runtime. > + */ > +static bool topology_matches_l3(struct mpam_class *victim) > + > static int mpam_resctrl_control_init(struct mpam_resctrl_res *res, > enum resctrl_res_level type) > { > struct mpam_class *class = res->class; > + struct mpam_props *cprops = &class->props; > struct rdt_resource *r = &res->resctrl_res; > > switch (r->rid) { > @@ -361,6 +531,20 @@ static int mpam_resctrl_control_init(struct mpam_resctrl_res *res, > * 'all the bits' is the correct answer here. > */ > r->cache.shareable_bits = resctrl_get_default_ctrl(r); > + break; > + case RDT_RESOURCE_MBA: > + r->alloc_capable = true; > + r->schema_fmt = RESCTRL_SCHEMA_RANGE; > + r->ctrl_scope = RESCTRL_L3_CACHE; > + > + r->membw.delay_linear = true; > + r->membw.throttle_mode = THREAD_THROTTLE_UNDEFINED; > + r->membw.min_bw = get_mba_min(cprops); > + r->membw.max_bw = MAX_MBA_BW; > + r->membw.bw_gran = get_mba_granularity(cprops); > + > + r->name = "MB"; > + Probably should be consistent with either a blank line before break or not. That might also make the diff a little nicer. > break; > default: > break;