Re: [PATCH v11 10/23] x86/resctrl: Remove MSR reading of event configuration value

[James Morse]

Hi Tony, Reinette,

On 2/6/25 15:56, Luck, Tony wrote:
> > > > This new arch API has sharp corners because of asymmetry of where resctrl
> > > > runs the arch function. I do not think it is required to change this since we
> > > > can only speculate about how this may be used in the future but I do think
> > > > it will be helpful to add comments that highlight:
> > > >
> > > > resctrl_arch_mon_event_config_get() ->  May run on CPU that does not belong to domain.
> > > > resctrl_arch_mon_event_config_set() ->  Runs on CPU that belongs to domain.
> > >
> > > Here's a vague data point about the future to help with speculation.
> > >
> > > I have something coming along the pipeline that also can run on any CPU.

RISC-V has this - all their controls/monitors are accessible from any CPU.
Some MPAM platforms can do this too - but the code has to be structured for those
that need the IPI.

Having this be something resctrl can be told sounds like a great idea.

It sounds like all or nothing suits x86/riscv.
The MPAM driver has an accessibility cpumask for each thing it accesses that determines
if it needs to do an IPI.


> > > I am contemplating a flag in the rdt_resource structure (in appropriate substructure
> > > resctrl_cache/resctrl_membw) to indicate "domain" vs. "any" for operations.
> > >
> > > Would something like that be useful here?
> >
> > hmm ... I cannot envision how this may look. Could you please elaborate?
> >
> > You mention "a" (singular) flag in rdt_resource while this scenario involves
> > different ops having different scope. This makes me think that this flag may
> > have to be per operation that in turn would need additional infrastructure to
> > manage and track operations.
> >
> > These "arch" functions are evolving as the work to support MPAM is done and
> > so far I think it has been quite ad-hoc to just refactor arch specific code
> > into "arch" helpers instead of keeping track of which scope they are running in.
> > This currently requires any arch implementing an "arch" helper to be well aware
> > of how resctrl will call it.

This is how APIs in linux evolve - only the immediate problem needs solving.
Arch code being aware how resctrl uses a function shouldn't be surprising - it is the only user.


> I haven't fleshed it out yet. One option would be to have a "choose_cpu_mask()"
> function that takes resource and domain parameters (and given your comment
> about this case an operation code). Then use that as the mask in an smp_call*().
>
> Operations that can run anywhere would return a mask with just bit for the
> current CPU.

That sounds like extra work. We already have a cpumask, if you set it to the cpu_possible mask
at boot, then smp_call_function() and friends will always prefer the current CPU, and it all falls
out in the wash.


Thanks,

James