[PATCH] malloc: Use __get_nprocs on arena_get2 (BZ 30945)

[Adhemerval Zanella Netto]

On 11/10/23 17:34, DJ Delorie wrote:
> Adhemerval Zanella Netto <adhemerval.zanella@linaro.org> writes:
>> Yes, that was your rationale on the previous attempt [1].  Maybe adding a
>> tunable, so if you are using affinity you can change thie behavior? 
> 
> We have a tunable to set the max arenas already.
> 
> Measuring the number of runnable CPUs seems more of a "correctness"
> thing to me.  This code is only called when we need to create a new
> arena, so it's not in a performance-critical path.  It's more important
> to get this right so that the rest of the code maximizes performance.

I agree, my main problem with this change it was originally unintentional.
My suggestion would to revert it back, and proper change with a meaningful
commit message that it is intentional and process that use setaffinity 
and see contention increase the max arenas.

> 
>> In any case, I think we should either close the bug or fix this and work
>> on a better heuristic to handle process that set affinity.
> 
> It sound like we need something between get_nprocs and get_nprocs_sched
> that counts the number of cores the program is assigned, not the number
> of cores the thread is assigned?  I thought that's what
> sched_getaffinity() did, but the man page says "process" most of the
> time, but sometimes "thread".
> 

The sched_getaffinity on Linux is essentially pthread_getaffinity_np,
since the cpu mask is per process attribute.  And I couldn't find any
procfs way to access the AND mask of all mask withins the thread group.

And I see no easy way to accomplish it, iterating over the /proc/self/task
is way too slow and do not scale.  Best option I can think of is add
a global mask and keep track of set bits on each sched_setaffinity
successful call; but it would require at least some global locking to
avoid racy conditions.