diff --git a/glibc-RHEL-61560.patch b/glibc-RHEL-61560.patch new file mode 100644 index 0000000..e8cbb22 --- /dev/null +++ b/glibc-RHEL-61560.patch @@ -0,0 +1,60 @@ +commit 226476e32251b5688eead482a9338c04ce84d715 +Author: Siddhesh Poyarekar +Date: Thu Jan 30 10:05:17 2025 -0500 + + manual: Explain sched_yield semantics with different schedulers + + The manual entry for sched_yield mentions that the function call could + be a nop if there are no other tasks with the same absolute priority. + Expand the explanation to include example schedulers on Linux so that + it's clear that sched_yield may not always result in a different task + being scheduled. + + Signed-off-by: Siddhesh Poyarekar + Reviewed-by: Joseph Myers + +diff --git a/manual/resource.texi b/manual/resource.texi +index f9fba2ad9cd84c14..c4204dc7a104d72e 100644 +--- a/manual/resource.texi ++++ b/manual/resource.texi +@@ -929,18 +929,31 @@ function, so there are no specific @code{errno} values. + @c Direct syscall on Linux; alias to swtch on HURD. + + This function voluntarily gives up the task's claim on the CPU. +- +-Technically, @code{sched_yield} causes the calling task to be made +-immediately ready to run (as opposed to running, which is what it was +-before). This means that if it has absolute priority higher than 0, it +-gets pushed onto the tail of the queue of tasks that share its ++Depending on the scheduling policy in effect and the tasks ready to run ++on the system, another task may be scheduled to run instead. ++ ++A call to @code{sched_yield} does not guarantee that a different task ++from the calling task is scheduled as a result; it depends on the ++scheduling policy used on the target system. It is possible that the ++call may not result in any visible effect, i.e., the same task gets ++scheduled again. ++ ++For example on Linux systems, when a simple priority-based FIFO ++scheduling policy (@code{SCHED_FIFO}) is in effect, the calling task is ++made immediately ready to run (as opposed to running, which is what it ++was before). This means that if it has absolute priority higher than 0, ++it gets pushed onto the tail of the queue of tasks that share its + absolute priority and are ready to run, and it will run again when its + turn next arrives. If its absolute priority is 0, it is more + complicated, but still has the effect of yielding the CPU to other +-tasks. +- +-If there are no other tasks that share the calling task's absolute +-priority, this function doesn't have any effect. ++tasks. If there are no other tasks that share the calling task's ++absolute priority, it will be scheduled again as if @code{sched_yield} ++was never called. ++ ++Another example could be a time slice based preemptive round-robin ++policy, such as the @code{SCHED_RR} policy on Linux. It is possible ++with this policy that the calling task is scheduled again because it ++still has time left in its slice. + + To the extent that the containing program is oblivious to what other + processes in the system are doing and how fast it executes, this diff --git a/glibc.spec b/glibc.spec index 58b8320..894e072 100644 --- a/glibc.spec +++ b/glibc.spec @@ -157,7 +157,7 @@ end \ Summary: The GNU libc libraries Name: glibc Version: %{glibcversion} -Release: 186%{?dist} +Release: 187%{?dist} # In general, GPLv2+ is used by programs, LGPLv2+ is used for # libraries. @@ -1184,6 +1184,7 @@ Patch876: glibc-RHEL-46726-15.patch Patch877: glibc-RHEL-46737-1.patch Patch878: glibc-RHEL-46737-2.patch Patch879: glibc-RHEL-46737-3.patch +Patch880: glibc-RHEL-61560.patch ############################################################################## # Continued list of core "glibc" package information: @@ -3177,6 +3178,9 @@ update_gconv_modules_cache () %endif %changelog +* Tue Apr 8 2025 Florian Weimer - 2.34-187 +- Document behavior of sched_yield with SCHED_RR and SCHED_OTHER (RHEL-61560) + * Tue Apr 8 2025 Florian Weimer - 2.34-186 - Increase reliability of stdio-common/tst-setvbuf2 (RHEL-46737)