Re: [PATCH] rteval: Fix loads cpulist restriction

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxxxx>
>
> 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 :)




[Index of Archives]     [RT Stable]     [Kernel Newbies]     [IDE]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux ATA RAID]     [Samba]     [Video 4 Linux]     [Device Mapper]

  Powered by Linux