From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-lf1-f47.google.com (mail-lf1-f47.google.com [209.85.167.47]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 30323339714 for ; Tue, 18 Aug 2026 17:04:28 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.167.47 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787072669; cv=none; b=AUTPO9YRb3OVcKLeOxS5LBBKWvA7SOExUmXBesDFBncyFtYRAtRJvL4aZV1BmVkTdWEHehI8IBpG/YFB32Fs5+qx9F2VO1DGpUqIyAxlwVJkIyDfVTt5vyA0cVE0WJfC1B/gEh5wlYM+30821lZCmJzK+bu4mcP7k1HDQ6+drN4= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787072669; c=relaxed/simple; bh=RzcrWRYAnas3w7gRJtgNkcOlP/3BOBx8AGcoQJF/vuw=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=fOsxE7N4m7XxUQiL1T9gwfRT+XsD/mOvF1FI+a6vCiKK4hYHu7A+jveai9N95zM3bgSKYyIK3zu1jKaXfQSBtpDkDltPKcOKmfMwyq1PGnHR5/CVxP6/WzoyOOnF9E5R2V8MMNeWaw4alv380gbe8Ty+aDDV1MIkcsMamGo081E= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=nKYHA8Mw; arc=none smtp.client-ip=209.85.167.47 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="nKYHA8Mw" Received: by mail-lf1-f47.google.com with SMTP id 2adb3069b0e04-5b0231a3e86so121676e87.0 for ; Tue, 18 Aug 2026 10:04:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1787072666; x=1787677466; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to:content-type; bh=lrGDoBIL3iWhxhs+JqbF1vE+9puinMdhn+njQDs42ho=; b=nKYHA8MwUCGBOCpfiKjC0NIACkIOCMYsAGlX387Ok1ChQXy76EFI3vqyOZcJwO33lp 89c9dksyEwe9Onk8SfZzTGPIJajxqYkgVIc0zUycIj6EC8PLf2Y5Vty+Ca9dTQ7uyqr2 BiBbjozLhNiyqY8mPqhe7XeVUUnH4YzXgAWJtEJvtj2wg0zBkiV/tX9av0syKPCihzMF 9tvVjxoVer+0rhwK4VRzzIZ0xZ2noRnN6muCQh2vGW+DSStlD/Ui/z4V8rpoiJV19W6+ /0IE3AjitjmGszm6ZJxr/rxCAOjvWal70Rvqrwn7ZeiuT29nf3tCXFljL0YoTEQA9nc3 jwXQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1787072666; x=1787677466; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to:content-type; bh=lrGDoBIL3iWhxhs+JqbF1vE+9puinMdhn+njQDs42ho=; b=pOHeP7iMs0D77TM5h4AIOO4DlcTVVDi0TUUhyIi9c6bv/7v9+itgUzF6Y6FjJofFVt 2cxgq9Nreya/nJOv6rfQh6Yw5gIJxhwMMkTrnrlb23XlBYFbldEpNcYvU6w2dOGP6kok yYW6D5MDz5WCVv+F7f4XX7aseYtjnyaBSSXLKKvNz/A4+QUFD1QprE1q6URKAmaozaZD Hh3OAdVngRPR4inTc5CO+QsjquIInEmpiSTQuydljBq7c9a10Ks26aFqAus6OmvR6Rka 7d+ic74iUj+GrnkJTnPh3/A8P+nmRElNxIsuZyvXPRjxUN25UGToQT9A7svmQxZjRVPU Iz8w== X-Forwarded-Encrypted: i=1; AHgh+Ro3sfednGd6/UtrR86ilp8IBzUdJ3XNIOwoznSDUlFnGqaEU0RrSRs/BKWizvP2QCnSl24RjlmYgSQVy2k=@vger.kernel.org X-Gm-Message-State: AOJu0YyvVXAc1wUfDbvZSic+dsTTgTZesG0DMDI1RSutnrn5PI0K+SWM J1huWfZIGfTtJXgStM4xh5vQWQcNQF0Ufoa/D6WPVAUFd8MPRtMkDvQ= X-Gm-Gg: AR+sD11KbwxCsmGwtNuyN75YL1oRLH9gOZSTWTrmGCLkVW+ZCEkbg1aGlxCYH38Quhm dZogFHBLMVGfAYfcNmC8q2l3Xbunwg6JTB/fL4RdpcdmShP5sLXUgfw5m3/9BjbnUYUEyqGH+dy Ob84qwNXsvjgEFj4SkXj2Yvcrs/bUHTpKgxw8SHBW8CBHPLvqKASqMktkflTsIwRTN23nQ5U37f tvhr9s1bxQYHEMGkLJjC2kgE2AfVTESR4hli2zjvX/ORsTvv0WBAvlmlVeDMCSsTUsFZjL+EsbG Fk85uyyDA+DDDVxEpm7QfuMQsXW+XIhXCB5BuVSLajNsp7zo/1tHF5dSNQme4o/dh/5VS1jWjCp gWIqFswNvTSqf0t5hU52cZC2abrUTJYv7kEtNCGEagsS2xq0INKEGavGESx+fhaAcX+3bQl79im oV8a73o5ozVmr5g7JMt6s21HC7pEMjtoGnJR+WpJHtmKOgHFZoOeILKuryEkK0MA== X-Received: by 2002:a05:6512:1287:b0:5b0:eda:de1f with SMTP id 2adb3069b0e04-5b459102745mr6076881e87.6.1787072666067; Tue, 18 Aug 2026 10:04:26 -0700 (PDT) Received: from fedora ([46.8.219.5]) by smtp.gmail.com with ESMTPSA id 2adb3069b0e04-5b46d01a089sm1367361e87.71.2026.08.18.10.04.25 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 18 Aug 2026 10:04:25 -0700 (PDT) From: Vitaliy Sochnev To: davem@davemloft.net, edumazet@google.com, kuba@kernel.org, pabeni@redhat.com Cc: horms@kernel.org, weiwan@google.com, netdev@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH net] net: yield the CPU on every exit of the threaded NAPI poll loop Date: Tue, 18 Aug 2026 20:04:20 +0100 Message-ID: <20260818190420.21204-1-sochnev.v.74@gmail.com> X-Mailer: git-send-email 2.55.0 In-Reply-To: <20260817183356.4d90d878@kernel.org> References: <20260817183356.4d90d878@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit > Please try to repro this on Linus's tree and repost if you can. > Don't recall the exact details but IIRC the preemption is now > more aggressive. The patch itself is against current net/master already - that is the tree I generated and build-tested it on, and the loop there is unchanged: if (repoll || busy_poll_last_qs) { rcu_softirq_qs_periodic(last_qs); cond_resched(); } if (!repoll) break; The exit path still reaches neither call, which is the case the patch is about. So there is nothing to change in the posting itself; it is the numbers that come from 6.18. They come from 6.18 because that is the only kernel this board runs. Mainline carries just en7581-evb - the AN7581/AN7583 SoC dtsi and the board DTS exist only in OpenWrt, along with the airoha_eth changes that have not landed upstream yet. On preemption - I did measure that. Same board, same load, plain OpenWrt without the patch, the two halves differing only in the preemption model (verified in the built kernel .config): PREEMPT_NONE worst "ip link del" 248.48 s, 8 of 29 samples over 1 s, 8 classic + 48 expedited RCU stalls PREEMPT_LAZY worst 0.39 s, 0 of 177 samples, no stalls at the same packet rate, 80862 vs 80036 pkt/s. So you remember right: with lazy preemption the symptom is gone. What is left is PREEMPT_NONE and PREEMPT_VOLUNTARY builds. It is not explained by the NAPI thread being preempted more, though - nonvoluntary_ctxt_switches on that thread is 4.6/s under LAZY against 13.9/s under PREEMPT_NONE. The interrupt and batching pattern changes instead. I could not pin the mechanism down, so I am reporting the measurement rather than a conclusion. For what it is worth, the reproduction is not specific to this hardware: threaded NAPI can be turned on for any driver through /sys/class/net//threaded, and what the bug needs on top of that is little or no interrupt coalescing, so the poll loop is re-entered tens of thousands of times a second. If a mainline repro is a hard requirement here, I understand - the 6.18 data and the unchanged code path is what I have.