From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) (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 DE04E1991D4 for ; Tue, 24 Mar 2026 04:19:52 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.129.124 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774325994; cv=none; b=dLCXlBhKuVKEnCZ5fJf5EFeVnUh4GsluUrieL9Le3At0lQsbJb4eE7gitNm49cy0PeQg/dtSxhYX0dNC5Dbl4mZf0FpZMIwtkqyE2qQrBR9Jl/kflwtXW0bH2/nWB8QxBCxt6SKNVfZX7hMLuWZd48hEbzJOOLrQsnt3mrW8nuw= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774325994; c=relaxed/simple; bh=9+uz7CzlNFoa9gXf4VBkH0zGszG5dtCkLuUwv7W9JPI=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=uLBJ4m/adtrS/x5bKjxY5FkKRG5wrP9jAKDuo/yx6T8IG2rwT9eXm6nF1NlB+2PRHmGf7ETwaE3h3bxDlCPa8n2xt5UEzYou+Ph5A7fAwsmpgkoq4AZH9VFx7QIcNSTVQWk1N1ksSdD+DpbR3vEQhgARlmAfGdBy9aNKUfZmZws= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com; spf=pass smtp.mailfrom=redhat.com; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b=DGVpZLd2; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b=lG/TVyMG; arc=none smtp.client-ip=170.10.129.124 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=redhat.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="DGVpZLd2"; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b="lG/TVyMG" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1774325991; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=R08g5rCsq9whHw36ZZYWUOiHQj5R1FuEsuKvwJiGAyE=; b=DGVpZLd2K8LXDRJ3uJhkPcA4RcO+zhbKHxzw/fRJMZid+So4nvKjMGXEIx17bIQjHAxG1D Cg9QESJwkytCViSJmQvv8L9Qj6+6A/c6C4NrxaEnLnWr/9MNRsUDNjZ2MjvgHRV9/AGk/c /v0ZVRs68yZe6PsyMTikRrlzjjlgk9A= Received: from mail-pl1-f198.google.com (mail-pl1-f198.google.com [209.85.214.198]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-643-sslIRmPmOG6NIWLXInr8KQ-1; Tue, 24 Mar 2026 00:19:50 -0400 X-MC-Unique: sslIRmPmOG6NIWLXInr8KQ-1 X-Mimecast-MFC-AGG-ID: sslIRmPmOG6NIWLXInr8KQ_1774325989 Received: by mail-pl1-f198.google.com with SMTP id d9443c01a7336-2b0601ff3d9so16225215ad.2 for ; Mon, 23 Mar 2026 21:19:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=google; t=1774325989; x=1774930789; darn=vger.kernel.org; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=R08g5rCsq9whHw36ZZYWUOiHQj5R1FuEsuKvwJiGAyE=; b=lG/TVyMGQ4ELslcBGA6ZMLM7odjpxdflIn8RoU8uc2GGAJlkPJErYil72xE2YJCr6i WjDvH1FOzjkHeL1doRwB+xt8BGUMqTS0iZRV+i6nOpnOU66hLqRVl2MDX6gM7feY6xD7 /r78sr02kVEEWPr0OJGitaSmrt7+2tprlkZGVHlYXhMWASvpBxPtNG3z5K7hTJvNZsCw vwb+teYKa0IDfQUZV61SvR9GqdRDHhfb1ooppCxcnVbreoIi/NdK01+v3+dZBHs10tQI GI2aGUVJ3o0hHZOd4CvXBuJdKQ7Reh9Yt24T+G78W5KUOCZrr4oLaxDTduqV1zXGrzXj NoYA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1774325989; x=1774930789; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=R08g5rCsq9whHw36ZZYWUOiHQj5R1FuEsuKvwJiGAyE=; b=nPJVoqLlf+iuwN6I/uA/GCyfMpKTe2TzQ77pVvmTuOoy6JQOFDPeHinZib/yODlhih fZx5OoLNQAE2BhSH5dsv3uC2kZzSAxbpDUoBCRpI4MVakPk/NQK3XX9jNAw+TqK/+NrI WejbsRyM3ofCuKSDCa5/BKCOpwdIIqwJOjUMikjqZmI1B94bOx7aCNlbM+5/kpKgKjcM ZyNCk5ScJObnEdqfLSurhPrINel65FGvBuhQSsL9yUd8EQKzVhrKsPz3zpVxZ4SbIfQ9 3OMxp9ETyV/g3GSPD8w051kNMGyWSgLkrBBBzYEWP6S/Y14g4RzK4LSQL0IgJco46HCn T8dQ== X-Forwarded-Encrypted: i=1; AJvYcCVOZj2DIARApwIW6NsXJ8K7viOT7CU6TVv3UJwCzyE78RcGE8XUnorm1SKapM1ysTDj9hU7PeomVkyxyi4=@vger.kernel.org X-Gm-Message-State: AOJu0YxyKI64WLWJ7el+MGEAfJWNg2Qx8qT5xLviRZyOjdirhJx2cj8i waDvxmN7ikAoDQsJrarwKBZMp8wYmqmoZQJ4UUOPbqrlBSaOXJ/hFimED2p+eJj1vaez0A+Owlk U5OqmP20KogeqUNg5ALx4dU4/uVpaT+4XqIChfOQIujDxiOZOqLvZZmVola0SRoxyZQ== X-Gm-Gg: ATEYQzx0WKr5felL1xGWtgHyzYu7UY8COPyNzMXy6eJ3bAiVsCa0FN7eMmK9XU7HYc3 RWIk/8DjrFkRuMlKDleSb2Yp68J/yTGPR6KZ36lsNXNqJRvkbJQkNGMolaO/KKSKLTY91AjClmZ KLgxJgBXWyk1cwEZ7w6tYXGm3QSVEA1Ntm0Rj8UgZEbaR8Lix4RdLR/3OE8STEsHxCucauHGFii F9Y1x+8R6yLGEm+dTBK0iygIN3s1o7B8DPRb+iayV/meukov4XGv4HHjXldqCH7Hs8MNPTGslAJ 0NAqzeE9EQn1VvfwGaOLsMT6nk/ZqfhnLIs0Tz3lM8uy4tCCpO99vkHCxCJooBx13rOOnSpBNRj GRL6uGF96BV59k1wjmWWNIJdfRjTgxI5vby0A6tOPkGT4qCnk8V1ZGZWqFYGeErR+ X-Received: by 2002:a17:903:94e:b0:2ae:826f:2c50 with SMTP id d9443c01a7336-2b0826e2f0emr124388535ad.12.1774325989075; Mon, 23 Mar 2026 21:19:49 -0700 (PDT) X-Received: by 2002:a17:903:94e:b0:2ae:826f:2c50 with SMTP id d9443c01a7336-2b0826e2f0emr124388145ad.12.1774325988661; Mon, 23 Mar 2026 21:19:48 -0700 (PDT) Received: from [192.168.68.51] (n175-34-8-244.mrk21.qld.optusnet.com.au. [175.34.8.244]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-2b083516ae1sm121045485ad.13.2026.03.23.21.19.33 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 23 Mar 2026 21:19:47 -0700 (PDT) Message-ID: <48fdab87-7caa-4e84-803f-3fbad3dd306b@redhat.com> Date: Tue, 24 Mar 2026 14:19:31 +1000 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v6 37/40] arm_mpam: Add workaround for T241-MPAM-4 To: Ben Horgan Cc: amitsinght@marvell.com, baisheng.gao@unisoc.com, baolin.wang@linux.alibaba.com, carl@os.amperecomputing.com, dave.martin@arm.com, david@kernel.org, dfustini@baylibre.com, fenghuay@nvidia.com, james.morse@arm.com, jonathan.cameron@huawei.com, kobak@nvidia.com, lcherian@marvell.com, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, peternewman@google.com, punit.agrawal@oss.qualcomm.com, quic_jiles@quicinc.com, reinette.chatre@intel.com, rohit.mathew@arm.com, scott@os.amperecomputing.com, sdonthineni@nvidia.com, tan.shaopeng@fujitsu.com, xhao@linux.alibaba.com, catalin.marinas@arm.com, will@kernel.org, corbet@lwn.net, maz@kernel.org, oupton@kernel.org, joey.gouly@arm.com, suzuki.poulose@arm.com, kvmarm@lists.linux.dev, zengheng4@huawei.com, linux-doc@vger.kernel.org, Shaopeng Tan References: <20260313144617.3420416-1-ben.horgan@arm.com> <20260313144617.3420416-38-ben.horgan@arm.com> Content-Language: en-US From: Gavin Shan In-Reply-To: <20260313144617.3420416-38-ben.horgan@arm.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 3/14/26 12:46 AM, Ben Horgan wrote: > From: Shanker Donthineni > > In the T241 implementation of memory-bandwidth partitioning, in the absence > of contention for bandwidth, the minimum bandwidth setting can affect the > amount of achieved bandwidth. Specifically, the achieved bandwidth in the > absence of contention can settle to any value between the values of > MPAMCFG_MBW_MIN and MPAMCFG_MBW_MAX. Also, if MPAMCFG_MBW_MIN is set > zero (below 0.78125%), once a core enters a throttled state, it will never > leave that state. > > The first issue is not a concern if the MPAM software allows to program > MPAMCFG_MBW_MIN through the sysfs interface. This patch ensures program > MBW_MIN=1 (0.78125%) whenever MPAMCFG_MBW_MIN=0 is programmed. > > In the scenario where the resctrl doesn't support the MBW_MIN interface via > sysfs, to achieve bandwidth closer to MBW_MAX in the absence of contention, > software should configure a relatively narrow gap between MBW_MIN and > MBW_MAX. The recommendation is to use a 5% gap to mitigate the problem. > > Clear the feature MBW_MIN feature from the class to ensure we don't > accidentally change behaviour when resctrl adds support for a MBW_MIN > interface. > > Tested-by: Gavin Shan > Tested-by: Shaopeng Tan > Reviewed-by: Zeng Heng > Reviewed-by: Shaopeng Tan > Reviewed-by: Fenghua Yu > Signed-off-by: Shanker Donthineni > Signed-off-by: James Morse > Signed-off-by: Ben Horgan > --- > [ morse: Added as second quirk, adapted to use the new intermediate values > in mpam_extend_config() ] > > Changes since rfc: > MPAM_IIDR_NVIDIA_T421 -> MPAM_IIDR_NVIDIA_T241 > Handling when reset_mbw_min is set > > Changes since v3: > Move the 5% gap policy back here > Clear mbw_min feature in class > > Changes since v5: > Calculate min from max when resetting > --- > Documentation/arch/arm64/silicon-errata.rst | 2 + > drivers/resctrl/mpam_devices.c | 55 +++++++++++++++++++-- > drivers/resctrl/mpam_internal.h | 1 + > 3 files changed, 55 insertions(+), 3 deletions(-) > Reviewed-by: Gavin Shan