Bug 29975 - Search concurrency doesn't respect CPU affinity
Summary: Search concurrency doesn't respect CPU affinity
Status: RESOLVED FIXED
Alias: None
Product: elfutils
Classification: Unclassified
Component: debuginfod (show other bugs)
Version: unspecified
: P2 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2023-01-09 17:38 UTC by Ross Burton
Modified: 2023-01-11 15:34 UTC (History)
2 users (show)

See Also:
Host:
Target:
Build:
Last reconfirmed:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Ross Burton 2023-01-09 17:38:22 UTC
I've a machine with lots of cores (256) but debuginfod doesn't respect CPU affinity:

$ taskset -c 2 debuginfod -v
...
[Mon Jan  9 17:33:20 2023] (2351762/2351762): search concurrency 256

Instead of looking at the number of cores present, it should look at the number of cores available to it (sched_getaffinity()).
Comment 1 Frank Ch. Eigler 2023-01-09 17:42:28 UTC
> number of cores available to it (sched_getaffinity()).

Do you happen to be aware of a c++y front-end to this, which we could
use instead of std::thread::hardware_concurrency() ?
Comment 2 Ross Burton 2023-01-09 18:24:39 UTC
No, but the C isn't that difficult:

#define _GNU_SOURCE
#include <sched.h>

int ret, count;
cpu_set_t mask;

CPU_ZERO(&mask);
ret = sched_getaffinity(0, sizeof(mask), &mask);
// if non-zero, errno is set
count = CPU_COUNT(&mask);
Comment 3 Frank Ch. Eigler 2023-01-10 23:04:31 UTC
please check out commit 7399e3bd7eb72d045 on elfutils.git for a test patch
Comment 4 Frank Ch. Eigler 2023-01-11 15:34:36 UTC
Pushed to master as dcb40f9caa7ca30

Author: Frank Ch. Eigler <fche@redhat.com>
Date:   Tue Jan 10 17:59:35 2023 -0500

    debuginfod PR29975 & PR29976: decrease default concurrency
    
    ... based on rlimit (rlimig -n NUM)
    ... based on cpu-affinity (taskset -c A,B,C,D ...)
    
    Signed-off-by: Frank Ch. Eigler <fche@redhat.com>