[Bug libc/15630] Fix use of cpu_set_t with sched_getaffinity when booted on a system with more than 1024 possible cpus.

["carlos at redhat dot com" <sourceware-bugzilla at sourceware dot org>]

https://sourceware.org/bugzilla/show_bug.cgi?id=15630

--- Comment #8 from Carlos O'Donell <carlos at redhat dot com> ---
(In reply to Florian Weimer from comment #7)
> What is the actual problem that we are trying to fix?

Applications using a fixed cpu_set_t on a machine with more than 1024 CPUs
should always just work, but it doesn't.

> We could make sched_getaffinity succeed if the affinity mask contains only
> zero bits outside the mask buffer supplied by the application.  But then,
> the only way to run an application which specifies too small a set would
> require preventing the application from running on those extra CPUs.  This
> could leave parts of the machine unused.

This is a fine compromise.

The application was not designed to run on those CPUs anyway and need to be
rewritten. The point is to allow such binaries to continue to run. Otherwise
this is the equivalent of having broken compatibility.

> We cannot drop discard set bits because some concurrent algorithms need to
> know on which CPUs they can run.

Agreed. We can continue to return EINVAL in this case.

> I do not want to introduce a CPU number offset in user space (which could be
> used to run multiple small-affinity-set applications on all CPUs).  This is
> probably something for the kernel.  Container/namespace support for affinity
> masks may even make sense for other reasons.

I think with the above changes we could make this work.

-- 
You are receiving this mail because:
You are on the CC list for the bug.