From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from r3-23.sinamail.sina.com.cn (r3-23.sinamail.sina.com.cn [202.108.3.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id DDE4F3BBFAE for ; Wed, 5 Aug 2026 02:15:23 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=202.108.3.23 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785896129; cv=none; b=Sn/Fy+PV0e0zmXoxj0TuCVonZzHA3xuKGgk0ofJ9eG+mxWZA3Z5MROMDFUGNjmBhYFAdfsUynd0iHDAwx6X6qZrtKR1yBTt2lmVXYdBU8TEOsu0obYem1eBIkNWQEUn2Tx6oIxkZsHo7SoWT8PZUp5BV7qNRG2L2UTnT0+rG+yI= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785896129; c=relaxed/simple; bh=I+iFj1NFGHV/Q7vEkP/EqemSBBd2J3VdaXFAQeNube4=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=V2YhiZc07hhPQKXVQQmFmVDepHjsLTVCRwzQsFPlPWWyAwMN4ThJjP0k9WQMcclN9Vl3VXhEgLGLIdWb97mSYjkk4HYIwk36U56Rm7qhn+eTC4Ei5ismOtFlYg4d4GFmtq9M5IJcMsokm/tG03yzt7zJWtwP6M1BhOYqABvcJLs= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=sina.com; spf=pass smtp.mailfrom=sina.com; dkim=pass (1024-bit key) header.d=sina.com header.i=@sina.com header.b=A0T9R/hD; arc=none smtp.client-ip=202.108.3.23 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=sina.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=sina.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=sina.com header.i=@sina.com header.b="A0T9R/hD" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sina.com; s=201208; t=1785896124; bh=6AJmS/JzD/JoA9M1DqGv2F6ZcLvN/Pdgw3qBDifdNIA=; h=From:Subject:Date:Message-ID; b=A0T9R/hD3WSKw7r+f8L64iwetczcuYHDsG9hXbWKh6iNMg/AVQkrR/hI1d1zv5M2v +WNXRNVI2CQHKi4Dmhg6e5CJ5r3eOMlEsKE6Df7OvKaIs3/NIFFDTAMfRrBo6LHtKp FUWnacMUfCYTSpzPjPlTOrL493C4rb/b9h90xFoU= X-SMAIL-HELO: localhost.localdomain Received: from unknown (HELO localhost.localdomain)([221.216.154.155]) by sina.com (10.54.253.31) with ESMTP id 6A729C8D00000CF4; Wed, 5 Aug 2026 10:14:39 +0800 (CST) X-Sender: hdanton@sina.com X-Auth-ID: hdanton@sina.com Authentication-Results: sina.com; spf=none smtp.mailfrom=hdanton@sina.com; dkim=none header.i=none; dmarc=none action=none header.from=hdanton@sina.com X-SMAIL-MID: 4874466816529 X-SMAIL-UIID: A701E5A929A6495B9F8240773AEBDB3C-20260805-101439-1 From: Hillf Danton To: Vinicius Costa Gomes Cc: Peter Zijlstra , K Prateek Nayak , Christoph Lameter , linux-kernel@vger.kernel.org Subject: Re: [PATCH RFC] sched/fair: decline WF_SYNC stacking when waker LLC is the busier share Date: Wed, 5 Aug 2026 10:14:29 +0800 Message-ID: <20260805021430.957-1-hdanton@sina.com> In-Reply-To: <20260804-epoll-wasync-fix-v1-v1-1-a83b4c8e08ba@intel.com> References: Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit 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 > --- > 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.