Re: [PATCH] rteval: Fix loads cpulist restriction

[Clark Williams <williams@redhat.com>]

I think the recent slew of commit is John trying to clean up the mess
that David and I made, by removing duplicate functions.

I'm not against using a set instead of a list in the cpulist
structure, although at that point we might want to call it a cpuset
:).

On Fri, Aug 5, 2022 at 2:43 PM Valentin Schneider <vschneid@redhat.com> 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
>