Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.38 as permitted sender) client-ip=23.128.96.38;
Date:   Tue, 19 Sep 2023 09:40:13 -0700
From:   Tony Luck <tony.luck@intel.com>
To:     Peter Newman <peternewman@google.com>
Cc:     Reinette Chatre <reinette.chatre@intel.com>,
        "james.morse@arm.com" <james.morse@arm.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>,
        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: <ZQnO7XC2ygY6/Upe@agluck-desk3>
References: <SJ1PR11MB6083BC6B330FA7B7DFD3E76AFCE3A@SJ1PR11MB6083.namprd11.prod.outlook.com>
 <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>
 <CALPaoCj_oa=nATvOO_uysYvu+PdTQtd0pvssvm9_M1+fP-Z8JA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <CALPaoCj_oa=nATvOO_uysYvu+PdTQtd0pvssvm9_M1+fP-Z8JA@mail.gmail.com>
Precedence: bulk

On Tue, Sep 19, 2023 at 02:53:07PM +0200, Peter Newman wrote:
> Hi Tony,
> 
> On Wed, Sep 6, 2023 at 8:21 PM Tony Luck <tony.luck@intel.com> wrote:
> > I've just pushed an updated set of patches to:
> >
> >   git://git.kernel.org/pub/scm/linux/kernel/git/aegl/linux.git resctrl_v65
> 
> I'm trying to understand the purpose of the resctrl_resource struct
> defined here:
> 
> https://git.kernel.org/pub/scm/linux/kernel/git/aegl/linux.git/tree/include/linux/resctrl.h?h=resctrl2_v65#n356
> 
> >From the common fields, it seems to be something with a name and some
> info files that can be divided into domains and should be told when
> CPUs are hotplugged. (I skipped the scope field because I couldn't
> find any references outside fs/resctrl2/arch). The remaining fields
> are explicitly disjoint depending on whether we're talking about
> monitoring or allocation.
> 
> >From this I don't get a strong sense that a "resource" is really a
> thing and I think James's resctrl_schema struct only for the purpose
> of resource allocation was more the right direction for common code.
> Outwardly, resctrl groups seem to be the only thing relating
> monitoring to allocation.
> 

Peter,

It's a good question. I started out with separate control_resource and
monitor_resource structures, but combined them early on when it was
looking like the overall size wasn't all that big (for a structure that
will only have a dozen or so instances) and there were a bunch of common
fields. It would be easy to separate them again if consensus is that is
cleaner. There are only two places (currently) where code walks
resources of all types (mount and unmount). So no big hassle to replace
those with separate for_each_control_resource() and for_each_monitor_resource()

> I skipped the scope field ...

The scope field is for the module to tell the core code the granularity
of the control/monitor resource so it can build a custom domain list
based on L2 cache scope, L3 cache scope, NUMA ndoe scope, core scope,
or anything else that h/w folks dream up.  This means only the common
code needs to register a CPU hotplug notifier.

Note that there is no sharing of domains between modules to allow each
module to be fully independent of any other module. This also means
that the domain structure can have a common header, with some module
specific data allocated directly after ... though the need for that
might be going away as I implement James suggestion to keep the common
schemata parsing in the generic code.

> Is there a good reason for the common code to understand relationships
> between monitors and schemas with the same name? If not, I think it
> would make more sense to register monitors and control schemata
> independently.

I'm going back through my code now, breaking it into a patch series
that builds a piece at a time. One of many things to become clear as
I work through this is that the ".name" field in the resource isn't
really useful. It may disappear to be replaced more specific
fields based on usage. There's already one for the name of the "info/"
directory for the resource. I'm adding a "schemata_name" for control
resources. When I get to the monitor section I'll likley add a
field that gets used to construct the names of directories under
the "mon_data/" directories instead of using ".name". Doing that
would remove any apparent relationship between monitors and
schemas. There's no reason on X86 for them to be connected.

-Tony