From nobody Mon Jun 8 22:52:41 2026 Received: from SHSQR01.spreadtrum.com (mx1.unisoc.com [222.66.158.135]) (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 52BCA371068 for ; Tue, 26 May 2026 06:37:23 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=222.66.158.135 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779777447; cv=none; b=jn3c+S2Zkgp3zGr4/z5y3ZdtPkIvsV9KomdFDUlUiSMSEiZcc+ST8V3pm7MBQYbniOf38MwonG5wv3sINM7hTuGkxXxG7T6a8Pz8hpqMrbrpby7e4D1AwU5yqO++EYeMPNM/g7roDsfL6S3uulnUJXMeLo1Z8RLnFAtAOPLhVyo= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779777447; c=relaxed/simple; bh=6++EXalkr1z+1YxLK5Lqh9d9XYSOkDSGBELY93mK0ug=; h=From:To:CC:Subject:Date:Message-ID:MIME-Version:Content-Type; b=CFN23iADxifdguW6eVEzJ0fEb5gmRk9+L5v9ddRfmq1+ybfp797xsk7J0mtRIZuXf26EiLHzN4v9erYPWzfuucphNxdVoB5VYquKyd9kA/gOW7br7j4yrpn3GVCDbYNP8GmyaCM5INJy/ZY1cRF/IywR4FEJaaJM5uKRklraEF8= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=unisoc.com; spf=pass smtp.mailfrom=unisoc.com; dkim=pass (2048-bit key) header.d=unisoc.com header.i=@unisoc.com header.b=byeEHSRI; arc=none smtp.client-ip=222.66.158.135 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=unisoc.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=unisoc.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=unisoc.com header.i=@unisoc.com header.b="byeEHSRI" Received: from dlp.unisoc.com ([10.29.3.86]) by SHSQR01.spreadtrum.com with ESMTP id 64Q6b5MH064945; Tue, 26 May 2026 14:37:05 +0800 (+08) (envelope-from Xuewen.Yan@unisoc.com) Received: from SHDLP.spreadtrum.com (BJMBX01.spreadtrum.com [10.0.64.7]) by dlp.unisoc.com (SkyGuard) with ESMTPS id 4gPjcW1jZzz2LmTMS; Tue, 26 May 2026 14:33:15 +0800 (CST) Received: from BJ10918NBW01.spreadtrum.com (10.0.73.73) by BJMBX01.spreadtrum.com (10.0.64.7) with Microsoft SMTP Server (TLS) id 15.0.1497.48; Tue, 26 May 2026 14:37:02 +0800 From: Xuewen Yan To: , , , , , , CC: , , , , , , , , , Subject: [RFC PATCH] net/core: use wake_up_interruptible_poll() in sock_def_readable() Date: Tue, 26 May 2026 14:36:50 +0800 Message-ID: <20260526063650.952-1-xuewen.yan@unisoc.com> X-Mailer: git-send-email 2.25.1 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-ClientProxiedBy: SHCAS03.spreadtrum.com (10.0.1.207) To BJMBX01.spreadtrum.com (10.0.64.7) X-MAIL: SHSQR01.spreadtrum.com 64Q6b5MH064945 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=unisoc.com; s=default; t=1779777434; bh=djV8qmH+Giaw08bWUC0A/JKUSvRmpthyO/rKydTHshU=; h=From:To:CC:Subject:Date; b=byeEHSRISqyprBlQThzD8C5+xuk4M2PZ80/SNyPl6v+gbETvoaW4Zotkap/6xib9G QKJIWfR5xwCfsCy1ZcHGpVRr2Pya5dAS6+kN49kgjUJ/ZLRJRGI9ddU6LuJ9zH1p1C +pD8+ELuPMTI6YDbPJ702zcuww99uLNsVLCEegwdiZ8fcbK5S5EmdyjR1haYOg+Nnu jzG5MrsQQP8btShUAtDoL6m6rkOLNFuxrDMoczRXdwUocsC5Vd8wjbWpaowR0w44O4 RuByg8RZz6ynyvSVtKtP8bRS3pDpCdKt1N0uuWv2WpCVSVgAHksCxayNTLQffbv4lh /+YdaketGgtBw== sock_def_readable() currently uses wake_up_interruptible_sync_poll() to wake up tasks waiting for readable data on a socket. The _sync variant sets the WF_SYNC flag, which tells the scheduler that the waker will schedule away soon, so the wakee should stay on the same CPU to avoid needless cache bouncing. However, we found that the following stack: -vfs_write -sock_write_iter -unix_stream_sendmsg -sock_def_readable -__wake_up_sync_key In this process-context scenario, the waker does NOT go to sleep after the wakeup. With WF_SYNC, the scheduler is misled into placing the wakee on the waker's CPU (via wake_affine_idle()'s sync path when nr_running =3D=3D 1), causing both the sender and receiver to contend for the same CPU. This may hurt throughput for IPC workloads on multi-core systems where the sender and receiver could otherwise run in parallel on different CPUs. Switch to wake_up_interruptible_poll() which does not set WF_SYNC. This allows the scheduler to freely migrate the wakee to an idle CPU, enabling true parallelism between the sending and receiving processes. Co-developed-by: Guohua Yan Signed-off-by: Guohua Yan Signed-off-by: Xuewen Yan --- Note: The possible cost is that for softirq callers (TCP/UDP receive path), the w= akee may be migrated away from the current CPU where the received data is cache-hot. However, this is mitigated by: - The scheduler's existing wake_affine logic which already considers cache affinity regardless of WF_SYNC. We are not very familiar with the networking code here, so we would greatly appreciate any suggestions or advice from the community. Thanks=EF=BC=81 --- net/core/sock.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/net/core/sock.c b/net/core/sock.c index b37b664b6eb9..42ab9373194f 100644 --- a/net/core/sock.c +++ b/net/core/sock.c @@ -3611,7 +3611,7 @@ void sock_def_readable(struct sock *sk) rcu_read_lock(); wq =3D rcu_dereference(sk->sk_wq); if (skwq_has_sleeper(wq)) - wake_up_interruptible_sync_poll(&wq->wait, EPOLLIN | EPOLLPRI | + wake_up_interruptible_poll(&wq->wait, EPOLLIN | EPOLLPRI | EPOLLRDNORM | EPOLLRDBAND); sk_wake_async_rcu(sk, SOCK_WAKE_WAITD, POLL_IN); rcu_read_unlock(); --=20 2.25.1