Re: [PATCH RFC] sched/fair: decline WF_SYNC stacking when waker LLC is the busier share

[Hillf Danton <hdanton@sina.com>]

On Tue, 04 Aug 2026 16:14:05 -0700 Vinicius Costa Gomes wrote:
> Since commit 900bbaae67e9 ("epoll: Add synchronous wakeup support for
> ep_poll_callback"), epoll driven WF_SYNC wakeups have been "too
> strong" and could cause tasks to stack on a busy NUMA node while other
> nodes are relatively idle.
> 
> As commit 900bbaae67e9 ("epoll: Add synchronous wakeup support for
> ep_poll_callback") improves real workloads a revert is not the answer.
> The fix is to make the WF_SYNC "stack on waker" shortcut take into
> account the load on this and prev's LLC, rejecting the shortcut only
> when the waker (this) LLC is fully loaded and prev's LLC is less
> loaded than the waker's.
> 
> Signed-off-by: Vinicius Costa Gomes <vinicius.gomes@intel.com>
> ---
> We received a report of a regression on a openresty based
> workload (the main metric being tail latencies) on a CWF SNC3 single
> socket system, the main symptom that we could measure was one node
> being overloaded while the other nodes were relatively idle.
> 
> Further investigation showed that spreading the NIC RX interrupts over
> all NUMA nodes helped. Reverting commit 900bbaae67e9 ("epoll: Add
> synchronous wakeup support for ep_poll_callback") also helped.
> 
The irq approach is prefered because anything that gets the eevdf offloaded
is good, you see it is near to the knowall point, needless to say that they
lie in different layers and from the scheduling-cpu pov irq is a gray rhino
in the room while WF_SYNC is a tiger mosquito in the corner at best in your
case where the mosquito failed to understand your workload.