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

[Vinicius Costa Gomes]

Hillf Danton <hdanton@xxxxxxxx> writes:

> 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@xxxxxxxxx>
>> ---
>> 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.

I don't think irq spreading across NUMA nodes is that good of an idea on
low loads/by default, as it loses the locality that the kernel (even
with irqbalance) try to maintain. I used that as a hackish way of
testing "if I spread tasks, does it improve the tail latencies?".

Note that the "local-only reproducer" workload (memcached +
memtier_benchmark) runs over loopback (no NIC irqs here), I pin memtier
(the client) to one NUMA node, leave the server unpinned and I am able
to reproduce the issue: with the RFC patch the tail latencies reduce by
2-3x. (on the customer workload the impact is even higher)

My expectation was that the scheduler would be able to say: "ugh, even
though respecting WF_SYNC is good most of the cases, this isn't one of
them". And this is the spirit of the RFC, showing that those cases
exist and their impact.


Cheers,
-- 
Vinicius