From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 2139121B910 for ; Fri, 20 Dec 2024 18:10:57 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=217.140.110.172 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1734718258; cv=none; b=VnskI591NUYO3P598QG7FJdkE6NrXOT8X4XcaZVvhW6zEgwwYzONG0V1ZdNv1hY6ZKfnL6HB206wzNQtgiIiBfzBmeW1gYjLztFizM3Q0u21++CHQXjaOwRZscmAqU+fJBNTrnqkaEtLblRhl6YJIYeSW5brsUZmE7h48Ry+Xp0= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1734718258; c=relaxed/simple; bh=Vt/MwJAZQQL17ZiM1bKAmLtsH98qLjsdYyCudeUmIG8=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=qMgrLqTCFMwAOMH6fz20vXELGsl8ttWqXSpQjhfFPkKSMh7gDJ4FTzyV5UJLTBPHnjBQHgbqLcIZYXNLEv0fAcLn5hTsThgtldDwRs/I5gM7NGA5WnVWnvrD6Gi+pUEFj96J5T/haCq87gp9AN/crUH2LM/czhp64wf2GQA1z+8= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com; spf=pass smtp.mailfrom=arm.com; arc=none smtp.client-ip=217.140.110.172 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=arm.com Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id BA1B21596; Fri, 20 Dec 2024 10:11:24 -0800 (PST) Received: from [10.1.196.57] (eglon.cambridge.arm.com [10.1.196.57]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 5172A3F720; Fri, 20 Dec 2024 10:10:53 -0800 (PST) Message-ID: <5e6954de-c003-4438-ac01-7346ef7fcca7@arm.com> Date: Fri, 20 Dec 2024 18:10:48 +0000 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 v5 04/40] x86/resctrl: Use schema type to determine how to parse schema values To: Reinette Chatre , x86@kernel.org, linux-kernel@vger.kernel.org Cc: Fenghua Yu , 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, baolin.wang@linux.alibaba.com, Jamie Iles , Xin Hao , peternewman@google.com, dfustini@baylibre.com, amitsinght@marvell.com, David Hildenbrand , Rex Nie , Dave Martin , Shaopeng Tan References: <20241004180347.19985-1-james.morse@arm.com> <20241004180347.19985-5-james.morse@arm.com> <7f7db029-2e94-4cba-9019-70810ad43b48@intel.com> Content-Language: en-GB From: James Morse In-Reply-To: <7f7db029-2e94-4cba-9019-70810ad43b48@intel.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Hi Reinette, On 23/10/2024 22:14, Reinette Chatre wrote: > On 10/4/24 11:03 AM, James Morse wrote: >> diff --git a/include/linux/resctrl.h b/include/linux/resctrl.h >> index 496ddcaa4ecf..54ec87339038 100644 >> --- a/include/linux/resctrl.h >> +++ b/include/linux/resctrl.h >> @@ -192,6 +191,17 @@ enum resctrl_scope { >> RESCTRL_L3_NODE, >> }; >> >> +/** >> + * enum resctrl_schema_fmt - The format user-space provides for a schema. >> + * @RESCTRL_SCHEMA_BITMAP: The schema is a bitmap in hex. >> + * @RESCTRL_SCHEMA_RANGE: The schema is a number, either a percentage >> + * or a MBps value. > > The description of RESCTRL_SCHEMA_RANGE appears to aim to be specific. Considering this > it should also include the "multiples of one eighth GB/s" input option used on > AMD systems. I really don't want to define something like that as being general purpose. This is an intermediate step to splitting 'range' into: percentage, mibps or 'platform'. Eventually the AMD fraction-of-GB/s would be 'platform', with resctrl unable to tell user-space what the unit is (it doesn't today either). I have a series to do this for MPAM's cache-capacity scheme which takes a percentage for caches like L2 or L3. I'd like percentage to be something that can be specified as the schema format because that gives us the opportunity to expose common properties of percentage controls to user-space from the filesystem code. e.g. the schema format, percentage min and granularity - the last two can only be done today if its a bandwidth you control, and user-space just has to know what the format of the control is. Most of MPAMs controls are either bitmaps or something we can pretend is a percentage. The odd two are PRI (ority), which is some kind of cost or weight, and the bandwidth stride scheme, which is similarly a cost or weight. I'd describe these as 'platform' if they are ever supported upstream. If another architecture has a similar control format it can be added and those MPAM controls can be switched over. If you think the comment is too specific, I'll change it to say its a decimal number. Splitting it up into what that number means will come back in a later series. > The software controller is the only user of actual bandwidth and for its > use it should be "MiBps". This would no longer match the command line argument mba_MBps, or the other code comments. I don't think this is worth the churn as it could never be consistent. I'll add this as a future cleanup patch so we can see how noisy it is going to be. ( fs/resctrl/ctrlmondata.c | 4 ++-- fs/resctrl/internal.h | 2 +- fs/resctrl/monitor.c | 6 +++--- fs/resctrl/rdtgroup.c | 18 +++++++++--------- include/linux/resctrl.h | 10 +++++----- 5 files changed, 20 insertions(+), 20 deletions(-) ) Thanks, James