Thread (11 messages) 11 messages, 3 authors, 2021-02-19

Re: [PATCH] oslat: Fix --cpu-list won't allow to schedule on all possible cores

From: Daniel Wagner <hidden>
Date: 2021-02-19 08:16:59

Hi Peter,

On Thu, Feb 18, 2021 at 02:27:29PM -0500, Peter Xu wrote:
parse_cpumask() is too strict for oslat, in that use_current_cpuset() will
filter out all the cores that are not allowed for current process to run.  This
seems to be unnecessary at least for oslat.  For example, the bash process that
runs the oslat program may have a sched affinity of 0-2, however it's still
legal to have it start a oslat thread running on the cores outside 0-2 as long
as the follow up sched_setaffinity() will succeed.

numa_parse_cpustring_all() suites exactly for this case, which should already
have considered sysconf(_SC_NPROCESSORS_ONLN) limit.  Use that instead.

Since at it, also remove initialization of cpu_set variable otherwise it's
leaked in previous parse_cpumask too: numa_parse_cpustring_all() will return a
newly allocated buffer already.  Quotting from manual:

    numa_parse_nodestring() parses a character string list of nodes into a bit
    mask.  The bit mask is allocated by numa_allocate_nodemask().

    numa_parse_nodestring_all() is similar to numa_parse_nodestring, but can
    parse all possible nodes, not only current nodeset.
My 2 cents: If parse_cpumask() is to strict fix parse_cpumask() so all
tools do the same thing. Note parse_cpumask() contains a couple
of bugs:

"rt-numa: Use mask size for iterator limit"
"rt-numa: Remove max_cpus argument from parse_cpusmask"

Thanks,
Daniel
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help