Re: [patch] cyclictest: CPU affinity now takes arbitrary set of cpus.

[Clark Williams <clark.williams@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 1652 bytes --]

On Thu, 5 Dec 2013 16:29:37 -0800
Aaron Fabbri <ajfabbri@gmail.com> wrote:

> [This patch is rebased on latest rt-tests.git, and is available in the
> "delivery" branch at https://github.com/ajfabbri/af-rt-tests.git]
> 
> Change -a (affinity) option to take a set of CPUs, instead of just one.
> 
> e.g.
>   cyclictest -a4,6-8 -t5
> 
> will use 5 threads, assigned round-robin to the set of CPUs {4,6,7,8}.
> CPU 4 will get threads 1 and 5, CPU 6 gets thread 2, CPU 7 gets thread 3, and
> CPU 8 gets thread 4.
> 
> Although this builds without libnuma,  libnuma >= v2 is required for these
> arbitrary CPU sets.  With libnuma v1, the -a option behaves as before.  As
> before, compiling without libnuma is supported. The command usage help is fixed
> up at compile time to always show the correct usage of the -a option.
> 
> Also note that, since numa_parse_cpustring_all() wasn't available in early
> libnuma v2 versions, we use numa_parse_cpustring().  This means you'll have to
> use taskset in some cases (isolcpus kernel parameter) to add the desired CPUs to
> the set of allowed cores, e.g.:
> 
>   taskset -c4-6 cyclictest -a4-6
> 
> Tested without libnuma (numactl), and with versions 1.0.2 and 2.0.9-rc3.
> 
> Signed-off-by: Aaron Fabbri <ajfabbri@gmail.com>

Thanks, I cherry-picked the commit from your git tree (the included
patch was too badly line-wrapped for me to use it). The only issue I've
seen so far was that in display_help() your #endif picked up the -A
option which is not dependent on libnuma behavior, so I fixed that up. 

I'll do some testing and push a new rt-tests out soon.

Clark

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 836 bytes --]