Return from a sleep as soon as a wake arrives

[xalestar]

A guest thread parked in nanosleep does not notice a queued signal until its own 100 ms recheck quantum expires. sys_nanosleep splits the interval into 100 ms chunks and tests signal_pending between them, so the delay is uniform over 0 to 100 ms, about 50 ms on average, against 0.12 ms under Linux 6.12.

The wake those chunks stand in for already exists: queueing a guest signal, exit_group and futex_interrupt all reach wakeup_pipe_signal, and io.c and poll.c already join it. A pure timeout has no descriptor to watch alongside the pipe, so it parks on a condition variable added to that same call instead, which leaves all five existing callers of the signal covering it unchanged.

A signal, exit_group and an execve teardown end the sleep on the wake. An execve handed to the leader keeps the SLEEP_CHUNK_NS cadence: a handoff issues a stop request thousands of times a second, and answering every ring turns each into a guest-visible EINTR that the guest answers by reissuing the rest of its interval; the numbers that cost are below. One broadcast also wakes every sleeper, so the sleep claims a process-directed signal under sig_lock before reporting EINTR, reusing the pick rt_sigsuspend makes, moved into a helper in the first commit.

Reproduction

tests/test-nanosleep-signal-latency.c holds one thread in a sleep and times the gap between pthread_kill and the handler running, for both nanosleep and clock_nanosleep(TIMER_ABSTIME). The delay before the signal walks forward across iterations: a fixed delay phase-locks every iteration to one offset inside the quantum and reports that point as though it were the whole distribution.

On the parent commit the test fails with 60.6 ms and 28.9 ms medians against its 20 ms ceiling. With this change it passes, and it also passes under the QEMU reference lane.

tests/test-nanosleep-process-signal.c parks four threads in nanosleep and sends the group one kill(). Without the claim 2 to 4 sleepers return EINTR while the handler runs once; with it exactly one does, as under QEMU.

Measurements

	before	after	Linux 6.12
signal to handler, median of 12	50 ms	0.069 ms	0.12 ms
1 us sleep, min/median of 200	7 / 8 us	4 / 5 us
10 us sleep	18 / 20 us	15 / 17 us
100 us sleep	132 / 135 us	130 / 133 us
1 ms sleep	1051 / 1273 us	1111 / 1274 us

nanosleep, pselect and pthread_cond_timedwait_relative_np are indistinguishable in resolution at 200 samples (3 / 2 / 3 us for a 1 us request), so the primitive swap costs nothing. Short sleeps come out slightly faster because the old path rebuilt a timespec and ran the saturating remainder arithmetic once per chunk.

The stop cadence is what the 400 ms guest sleep in test-exec-handoff measures, under handoff pressure. It only separates the two revisions inside the full sanitizer suite; run on its own the test sits at 1800 to 2400 ms either way.

Same tree built with and without the change, alternating.

under make check-tsan	interruptions	sleep
before the change	3	432 ms
handoff stop tested on every wake	29390	3150 ms
this revision	3	403 ms

Commands

• make check, make check-tsan, make check-asan, make check-ubsan: all exit 0, with check-tsan green over four consecutive runs
• make check-format, make lint: exit 0
• make check-ascii: clean across 427 source files
• test-wakeup-pipe-host goes from 5 to 9 checks, covering the counter advancing, a stale counter not parking, a wait holding until the wake, and a signal releasing a parked wait

Rebased on 4023647.

---

Summary by cubic

Guest threads parked in nanosleep or clock_nanosleep(TIMER_ABSTIME) used to notice queued signals only when their 100 ms recheck quantum expired, adding about 50 ms average signal-to-handler latency. They now wake immediately via wakeup_pipe_signal(), cutting that to about 0.07 ms without regressing short sleeps.

Bug Fixes

• Pure timeout sleeps now park on a condition variable driven by wakeup_pipe_signal(), since they have no descriptor to watch; existing callers are unchanged.
• Adds an atomic wake counter so a wake that lands between a caller's predicate check and its park is not lost.
• Recomputes remaining sleep time from CLOCK_MONOTONIC, because the wait can return early on any process-wide wake.
• Keeps stop-request checks on the old recheck cadence; testing them on every wake would make exec handoffs produce a guest-visible EINTR storm.
• A process-directed signal is now claimed under sig_lock by one sleeper, so a single kill() interrupts one thread instead of every sleeper.
• Adds latency and process-signal tests and expands the host wakeup-pipe test to cover the condvar wait.

^{Written for commit 76ba1ad. Summary will update on new commits.}

[xalestar]

The TSAN red on the previous push came from moving both halves of the sleep's predicate onto the wake. They are not the same condition. A tagged counter over one run of test-exec-handoff under handoff pressure:

passes=45000 stop=22465 sig=20

Almost every early return was thread_stop_requested, not a queued guest signal. An exec handoff issues a stop request thousands of times a second, so testing it on every wake turns each ring into a guest-visible EINTR, and the guest answers each one by reissuing the rest of its interval.

This push tests signal_pending on every wake, which is what the change is for, and keeps thread_stop_requested on the SLEEP_CHUNK_NS cadence it had before, which is unchanged behaviour for that half.

The measurement only separates the two versions inside the full sanitizer suite. Run on its own the test sits at 1800 to 2400 ms either way; under make check-tsan:

	interruptions	sleep
before the change	3	432 ms
previous push	29390	3150 ms
this push	3	407 ms

make check-tsan is green over four consecutive runs here, as are check, check-asan, check-ubsan, check-format, lint and check-ascii. Signal to handler is unchanged at 0.053 to 0.074 ms.

[jserv]

thread_stop_requested() is three conditions, and only one of them is the handoff the EINTR measurement above is about. thread_stop_is_leader_work_only() already separates them, so exit_group and an execve teardown could be answered on the wake that is now in hand while the handoff keeps its SLEEP_CHUNK_NS cadence: stop_due || !thread_stop_is_leader_work_only(). As written, a guest thread in a multi-second sleep still holds up teardown for up to 100 ms after the wake has already reached it.

[xalestar]

The sleep tests thread_stop_requested() && (stop_due || !thread_stop_is_leader_work_only()), so exit_group and an execve teardown end it on the wake while the handoff keeps the SLEEP_CHUNK_NS cadence. The stop test also runs before the signal test, because a thread an execve reaps would otherwise claim a process-directed signal into its private set and take it along. Under make check-tsan the handoff sleep in test-exec-handoff is 403 ms across 3 interruptions, the same as without the change.

[jserv]

The settle delay is a guess, not a handshake. If the sleeper has not reached the wait when pthread_kill fires, the signal is answered by the signal_pending() test at the top of the sleep loop and the iteration records a fast gap on the unfixed tree too. A slow pthread_create under the sanitizer lanes can put several iterations in that state, and once half of them land there the median stops measuring the thing this test exists for. Have the sleeper publish an atomic flag immediately before it calls nanosleep and spin on that flag before the settle delay.

[xalestar]

The sleeper sets sleeper_armed immediately before nanosleep or clock_nanosleep, and median_gap spins on it, bounded at SLEEP_SEC, before the settle delay.

[jserv]

Both new waits assert only an upper bound, so a wakeup_wait_ns that returns at once and never parks passes them: it would report about 0 ms, well under the 1000 ms ceiling, and the stale-counter check above passes for the same reason. Add the lower bound that separates the two, something like waited_ms >= 40, since the ringer sleeps 50 ms before it signals.

[xalestar]

Added waited_ms >= 40. t0 also moved ahead of pthread_create: taken after it, a ringer already partway through its 50 ms could put a correct wait under the bound on a slow start.

[henrybear327]

This unblocks the LTP test! Thanks for this improvement! :)