Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.34 as permitted sender) client-ip=23.128.96.34;
Date:   Wed, 20 Sep 2023 17:21:12 -0700
From:   Tony Luck <tony.luck@intel.com>
To:     James Morse <james.morse@arm.com>
Cc:     Reinette Chatre <reinette.chatre@intel.com>,
        Babu Moger <babu.moger@amd.com>,
        Amit Singh Tomar <amitsinght@marvell.com>,
        "Yu, Fenghua" <fenghua.yu@intel.com>,
        George Cherian <gcherian@marvell.com>,
        "robh@kernel.org" <robh@kernel.org>,
        "peternewman@google.com" <peternewman@google.com>,
        Drew Fustini <dfustini@baylibre.com>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        "linux-arm-kernel@lists.infradead.org" 
        <linux-arm-kernel@lists.infradead.org>
Subject: Re: resctrl2 - status
Message-ID: <ZQuMeCCUm2sHuX8p@agluck-desk3>
References: <dc4cd365-2a02-32a3-da78-7ba745877e97@intel.com>
 <SJ1PR11MB6083C0ED50E9B644F4AF8E4BFCE3A@SJ1PR11MB6083.namprd11.prod.outlook.com>
 <fb9499b9-c445-01e8-8427-6b05256abdb5@intel.com>
 <ZOkU+d4AsLGSAG+y@agluck-desk3>
 <b48fe955-c1b4-4aeb-1ab0-bf26e56e1f0e@intel.com>
 <ZOlRNTq3lE7VNHjU@agluck-desk3>
 <9742f177-a0ce-c5d3-5d92-90dda32f5d07@intel.com>
 <ZPjDHN0nvHz9kWFn@agluck-desk3>
 <fa93564a-45b0-ccdd-c139-ae4867eacfb5@arm.com>
 <ZQTAuChYjK9Y93y7@agluck-desk3>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <ZQTAuChYjK9Y93y7@agluck-desk3>
Precedence: bulk

On Fri, Sep 15, 2023 at 01:38:16PM -0700, Tony Luck wrote:
> My PoC code went full throttle on pushing all the schemata code to the
> driver. But you are right that this may be too drastic.  Drivers could
> just indicate that they need one of the basic types "bitmap, percentage,
> number, bandwidth" together with some parameters (number of bits for
> bitmap, granularity for percentage, high/low values for number, ditto
> for bandwidth) and have core code handle the inital parsing. Then give
> to the module for validation (e.g. for the Intel requirement that
> cache bit masks have contiguous "1" bits), and some CPU models require
> that a minimum of two bits are set). Also pass to the module to apply
> (wrmsr() on a CPU in the domain for x86, MMIO from anywhere for ARM).
> 
> For bitmasks - MPAM seems to allow very long masks. Perhaps the kernel
> can make use of the "%*pb" format to scanf/printk to cope with those?
> It would mean commas in the masks like 0000,00000fff,ffffff00,0000000f

James,

Your earlier e-mail came at a fortuitous moment. I am breaking my
giant patches into smaller pieces. I had just got to the "add the
schemata file" section of the series. I took your advice and put
the majority of the parsing code into the core, leaving the arch
specific modules just a hook to handle weird quirks.

Modules specify the "type" of their schemata entries, together with
a parameter that the core can use. I implemented two types so far.
But should be easy to add additional types like "bandwidth" as you
had suggested.

1) Bitmask. Parameter is the number of bits.
2) Unsigned long. Parameter is the max value.

Examples of quirks:
1) Intel L3 CAT requires all "1" bits to be in a consecutive block.
   In this case core code will accept any bitmask that doesn't exceed
   the number of bits. The module can reject if the user doesn't
   follow the consecutive bits rule.
2) Intel L3 MBA requires that throttle percentage values be a multiple of the
   h/w enumerated granularity (e.g. 10%). Here the module does a
   roundup() to quietly fix invalid input (same as legacy resctrl).

I've only got through the "control" section of converting to patches.
But I think this is well past the halfway point.

Current snapshot of code is here:


git://git.kernel.org/pub/scm/linux/kernel/git/aegl/linux.git resctrl2_patches


* Comes with just the rdt_l3_cat and rdt_l3_mba modules.
  Without the AMD support bits at this point.
* No "cpus", "mode", "size" files yet.
* Just CTRL_MON directories.
* No monitoring support yet.

-Tony