Re: [PATCH] rteval: Fix loads cpulist restriction

[John Kacur <jkacur@redhat.com>]

On Fri, 5 Aug 2022, Valentin Schneider wrote:

> On 05/08/22 13:04, John Kacur wrote:
> > On Fri, 5 Aug 2022, Valentin Schneider wrote:
> >
> >> On 05/08/22 14:42, Valentin Schneider wrote:
> >> > A recent batch of commits, one of them being:
> >> >
> >> >   39115f0a826d ("rteval: Make use of systopology instead of misc in hackbench")
> >> >
> >> > has made the loads modules use CpuList.expand_cpulist() (which produces a
> >> > list(int)) instead of misc.expand_cpulist() (which produces a list(str)).
> >> > However, the bits handling restricting CPU affinity based on a user
> >> > argument still expects to handle a list(str), which results in:
> >> >
> >> >   [DEBUG] [kcompile] node 0 has no available cpus, removing
> >> >   [...]
> >> >   [DEBUG] [hackbench] node 0 has no available cpus, removing
> >> >
> >>
> >> This is lacking some context, so here's more:
> >>
> >> This was triggered on an arm64 system (Ampere eMAG), any sort of affinity
> >> restriction suffices, e.g.
> >>
> >>  $ rteval -O -D -v --loads-cpulist=2-3
> >>
> >> I can reproduce that on my x86 laptop:
> >>
> >>   $ sudo ./rteval-cmd -O -D -v --loads-cpulist=2-3
> >>   [DEBUG] [kcompile] systopology: 1 node system (8 cores per node)
> >>   [DEBUG] [kcompile] node 0 has no available cpus, removing
> >>   [DEBUG] [kcompile] node 0 has no available cpus, removing
> >>   [DEBUG] [hackbench] node 0 has no available cpus, removing
> >>
> >>
> > Thanks
> > Signed-off-by: John Kacur <jkacur@redhat.com>
> >
> > re python sets for cpu (cpuset is an overloaded term)
> > The idea isn't bad it could work.
> >
> > Right now I am trying reduce the number of duplicated interfaces.
> > Even a seemingly simple change to use lists of ints instead of lists of
> > strings of ints can uncover problems. So, I probbaly would not be so open
> > to python sets for cpus at the moment, but could be in the future.
> >
> > It is probably more work than you realize though, and I would require a
> > full solution, which means replacing the uses of the current interfaces in
> > cyclictest (measurement module), kcompile, hackbench, stressng. You could
> > create a personal fork and have a go at it though if you like!
> >
> 
> I think I'll tinker with a new class and figure out what features it would
> need, and then I'll sit on it and push it further down my todolist - like
> you said, the primary ingredient here is gonna be time :)
> 
> 
Also, CpuList was really just designed as a helper class to SysTopology 
and not really mean as a general interface. I do have plans to separate 
some of that functionality out into a more generic interace we can use.
It might make more sense at that time, to start thinking about whether 
sets would work better or not. So, like anything open source, you're 
welcome to play with it, but you might want to chat with me a little if 
you're serious about it, we could maybe hash out a coherent plan.

John