> >> 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. > > > > 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. Reinette, 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. Those tied to a domain, a copy of the domain mask. -Tony
