[patch v1] manual: add remaining CPU_* macros

Florian Weimer fweimer@redhat.com
Fri Apr 25 05:24:06 GMT 2025


* DJ Delorie:

> Adds remaining CPU_* macros, including the CPU_*_S macros
> for dynamic-sized cpu sets.
>
> diff --git a/manual/resource.texi b/manual/resource.texi
> index acdb1f3986..739c019c8c 100644
> --- a/manual/resource.texi
> +++ b/manual/resource.texi
> @@ -1424,6 +1424,39 @@ evaluated more than once.
>  This macro is a GNU extension and is defined in @file{sched.h}.
>  @end deftypefn
>  
> +@deftypefn Macro {cpu_set_t *} CPU_AND (cpu_set_t *@var{dest}, cpu_set_t *@var{src1}, cpu_set_t *@var{src2})
> +@standards{GNU, sched.h}
> +@safety{@prelim{}@mtsafe{}@assafe{}@acsafe{}}
> +@c CPU_AND ok
> +@c  __CPU_OP_S ok
> +This macro populates @var{dest} with only those CPUs included in both
> +@var{src1} and @var{src2}.  Its value is @var{dest}.
> +
> +This macro is a GNU extension and is defined in @file{sched.h}.
> +@end deftypefn

As a general comment, I think the fixed-size macros should be
deprecated.  Machines with more than 1024 CPUs are making a comeback.
The fixed-size cpu_set_t type does not work for them.  In particular,
sched_getcpu might fail.

Here's a recent example:

  [PATCH v2] nproc: Use affinity mask even on systems with more than 1024 CPUs
  <https://lists.gnu.org/archive/html/bug-gnulib/2024-11/msg00084.html>

  [PATCH] build: update gnulib to latest
  <https://lists.gnu.org/archive/html/coreutils/2024-11/msg00013.html>

Perhaps even quote the code in the first patch as an example in the
manual?

> +For applications that require CPU sets larger than the built-in size,
> +a set of macros that support dynamically-sized sets are defined.
> +
> +@deftypefn Macro size_t CPU_ALLOC_SIZE (size_t @var{count})
> +@standards{GNU, sched.h}
> +@safety{@prelim{}@mtsafe{}@assafe{}@acsafe{}}
> +@c CPU_ALLOC_SIZE ok
> +@c  __CPU_ALLOC_SIZE ok
> +Given a count of CPUs to hold, returns the size of the set to
> +allocate.  This return value is appropriate to be used in the *_S macros.
> +
> +This macro is a GNU extension and is defined in @file{sched.h}.
> +@end deftypefn
> +
> +@deftypefn Macro {cpu_set_t *} CPU_ALLOC (size_t @var{count})
> +@standards{GNU, sched.h}
> +@safety{@prelim{}@mtsafe{}@asunsafe{@asulock{}}@acunsafe{@aculock{} @acsfd{} @acsmem{}}}
> +@c CPU_ALLOC
> +@c  __CPU_ALLOC
> +@c   __sched_cpualloc
> +@c    malloc
> +Given the count of CPUs to hold, returns a set large enough to hold
> +them; that is, the resulting set will be valid for CPUs numbered 0
> +through @var{count}-1, inclusive.  This set is allocated with
> +@code{malloc} and must be freed via @code{CPU_FREE}.
> +
> +This macro is a GNU extension and is defined in @file{sched.h}.
> +@end deftypefn

Maybe mention explicitly that the argument is *not* the result of
CPU_ALLOC_SIZE?

If the allocation happens via malloc, why require that CPU_FREE must be
used?  Maybe drop the malloc reference in the visible text?

> +@deftypefn Macro void CPU_ZERO_S (size_t @var{size}, cpu_set_t *@var{set})
> +@end deftypefn
> +@deftypefn Macro void CPU_SET_S (int @var{cpu}, size_t @var{size}, cpu_set_t *@var{set})
> +@end deftypefn
> +@deftypefn Macro void CPU_CLR_S (int @var{cpu}, cpu_set_t *@var{set})
> +@end deftypefn
> +@deftypefn Macro {cpu_set_t *} CPU_AND_S (size_t @var{size}, cpu_set_t *@var{dest}, cpu_set_t *@var{src1}, cpu_set_t *@var{src2})
> +@end deftypefn
> +@deftypefn Macro {cpu_set_t *} CPU_OR_S (size_t @var{size}, cpu_set_t *@var{dest}, cpu_set_t *@var{src1}, cpu_set_t *@var{src2})
> +@end deftypefn
> +@deftypefn Macro {cpu_set_t *} CPU_XOR_S (size_t @var{size}, cpu_set_t *@var{dest}, cpu_set_t *@var{src1}, cpu_set_t *@var{src2})
> +@end deftypefn
> +@deftypefn Macro int CPU_ISSET_S (int @var{cpu}, size_t @var{size}, const cpu_set_t *@var{set})
> +@end deftypefn
> +@deftypefn Macro int CPU_COUNT_S (size_t @var{size}, const cpu_set_t *@var{set})
> +@end deftypefn
> +@deftypefn Macro int CPU_EQUAL_S (size_t @var{size}, cpu_set_t *@var{src1}, cpu_set_t *@var{src2})
> +@end deftypefn
> +
> +Each of these macros performs the same action as its non-@code{_S} variant,
> +but takes a @var{size} argument to specify the set size.  This
> +@var{size} argument is as returned by the @code{CPU_ALLOC_SIZE} macro,
> +defined above.

I think it would make sense to mention the *_S macros first and

Thanks,
Florian



More information about the Libc-alpha mailing list