From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id E39E2C4167B for ; Wed, 8 Nov 2023 12:16:35 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 661A680021; Wed, 8 Nov 2023 07:16:35 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 5E9228D00AD; Wed, 8 Nov 2023 07:16:35 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 488C580021; Wed, 8 Nov 2023 07:16:35 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 33A248D00AD for ; Wed, 8 Nov 2023 07:16:35 -0500 (EST) Received: from smtpin09.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 0426F40BB3 for ; Wed, 8 Nov 2023 12:16:34 +0000 (UTC) X-FDA: 81434685150.09.141C045 Received: from mail-ed1-f53.google.com (mail-ed1-f53.google.com [209.85.208.53]) by imf05.hostedemail.com (Postfix) with ESMTP id 3A6FD100019 for ; Wed, 8 Nov 2023 12:16:33 +0000 (UTC) Authentication-Results: imf05.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=r4stV+9m; spf=pass (imf05.hostedemail.com: domain of edumazet@google.com designates 209.85.208.53 as permitted sender) smtp.mailfrom=edumazet@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1699445793; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=Eih6T1QKUdzbWftoLZKbxzh3vZlf5WfPj/69P8AwcBM=; b=oQMnYxW9hjNEvF/aWDr6F45e3UHXrtvpF4/Ec6w5QEl0AHP5H61Nni8PpQfpRxg5nDY8N4 M2KxTQAP4vJZI6jZZMznX6mw/4uDwQq80u4YhXw5qnsryaApy8NNkU6bG2/3Bb8RnzWXtS V5jH+bZfpXVwPDNIPdn4lNBO1qWFYF8= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1699445793; a=rsa-sha256; cv=none; b=foRrx9hVeyAT+YYB8JghoiPZG+BNNzTNhSw4/QnHUtktJQCPVfDNRz/YYvrkxVC+6FRGSC NPXmv5Wc2re228jia3IxecISVaAMybs2lMS6Cu4hWaLkPU58YnVjkl0uIkZOc/L3TKv+iT o5TJssEBmdSgIqx3q35beuEe1BkJFTs= ARC-Authentication-Results: i=1; imf05.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=r4stV+9m; spf=pass (imf05.hostedemail.com: domain of edumazet@google.com designates 209.85.208.53 as permitted sender) smtp.mailfrom=edumazet@google.com; dmarc=pass (policy=reject) header.from=google.com Received: by mail-ed1-f53.google.com with SMTP id 4fb4d7f45d1cf-51e24210395so13497a12.0 for ; Wed, 08 Nov 2023 04:16:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1699445791; x=1700050591; darn=kvack.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=Eih6T1QKUdzbWftoLZKbxzh3vZlf5WfPj/69P8AwcBM=; b=r4stV+9m+qoyrizNlffkFMb6CbZEnIIQdUWCNaMKMjc5SIMEdRBczoO+pgmqQ33i/0 jGnqnGT4KfXsahRpUtBSLXklfP4B4s8vlg+0DAwn93hOLwRxvdf8kOcugGrzzE7kkjzX z+8jikiOqDD6PZ0WZ1vYM07tKBIybGr/PluMeun3aGZtffpNW2j2crNpFWstGmJ1dyZX crqD+Z/+g0RhvjxUfZaBx/Q7RvCJaEv7cnxLHYI6w3sZALetuMTZd0zxYQ8OFUMF4YNi i26UbY224hhaWdxfrOsJLW6ecQzCne0P/YqzknYwladUp9Zrg6S5HVrCrHZnoaKaOSZw jtnw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1699445791; x=1700050591; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=Eih6T1QKUdzbWftoLZKbxzh3vZlf5WfPj/69P8AwcBM=; b=kHRXZATBNKDoRnl78Kw49j0bFLOj2eU3Ai1x2x2f8rGWpxDl8jr+0yXnwS7vKI6RJM CNQXX9qZVAA5GKN+EaLr6JoFy2nOLTrKgv5VR47P7COD5bdMGBxRZ1FJ/a0Hq78fr1bN 4CQQsqJ1gIZJ3xWw7C5x9I7rFsa2Wa//QUCMxbS8gW3mGDlYugjgDEiADc75J0luOz+n EIK00PILbU4h8RbbkEnwYJnBIi0/UCC4vQzvJ7bf7oV1TlSu5y1k2lzACgprsRMLEZ3s zlTOmG62PKMLBAVhMXjZctLD+w933MJ5RrLaqsUzktzmZ5ZtgXBu0qnqj4cDqrulYOcn a5EA== X-Gm-Message-State: AOJu0YzipU/SKVl95Bx8A6pa72IhZKKieVI4t282dTULFP9A0epNpnwb 5JP5VA3DKFTKxtBPdRYQWgU8/DVyWhLaXFF5YgZfbg== X-Google-Smtp-Source: AGHT+IFBqcWVcXbeWVdYU+5QWKDwce1Q7jwMeN9FTTGoz3Sj6+w3rpciGJdvCu5o5z1HqGkOlbvdLWc23EcpzzPGbLI= X-Received: by 2002:aa7:d281:0:b0:545:3a48:ebab with SMTP id w1-20020aa7d281000000b005453a48ebabmr26889edq.5.1699445791385; Wed, 08 Nov 2023 04:16:31 -0800 (PST) MIME-Version: 1.0 References: <20231107215742.363031-1-ankur.a.arora@oracle.com> <20231107230822.371443-1-ankur.a.arora@oracle.com> <20231107230822.371443-23-ankur.a.arora@oracle.com> In-Reply-To: <20231107230822.371443-23-ankur.a.arora@oracle.com> From: Eric Dumazet Date: Wed, 8 Nov 2023 13:16:17 +0100 Message-ID: Subject: Re: [RFC PATCH 79/86] treewide: net: remove cond_resched() To: Ankur Arora Cc: linux-kernel@vger.kernel.org, tglx@linutronix.de, peterz@infradead.org, torvalds@linux-foundation.org, paulmck@kernel.org, linux-mm@kvack.org, x86@kernel.org, akpm@linux-foundation.org, luto@kernel.org, bp@alien8.de, dave.hansen@linux.intel.com, hpa@zytor.com, mingo@redhat.com, juri.lelli@redhat.com, vincent.guittot@linaro.org, willy@infradead.org, mgorman@suse.de, jon.grimm@amd.com, bharata@amd.com, raghavendra.kt@amd.com, boris.ostrovsky@oracle.com, konrad.wilk@oracle.com, jgross@suse.com, andrew.cooper3@citrix.com, mingo@kernel.org, bristot@kernel.org, mathieu.desnoyers@efficios.com, geert@linux-m68k.org, glaubitz@physik.fu-berlin.de, anton.ivanov@cambridgegreys.com, mattst88@gmail.com, krypton@ulrich-teichert.org, rostedt@goodmis.org, David.Laight@aculab.com, richard@nod.at, mjguzik@gmail.com, Marek Lindner , Simon Wunderlich , Antonio Quartulli , Sven Eckelmann , "David S. Miller" , Jakub Kicinski , Paolo Abeni , Roopa Prabhu , Nikolay Aleksandrov , David Ahern , Pablo Neira Ayuso , Jozsef Kadlecsik , Florian Westphal , Willem de Bruijn , Matthieu Baerts , Mat Martineau , Marcelo Ricardo Leitner , Xin Long , Trond Myklebust , Anna Schumaker , Jon Maloy , Ying Xue , Martin Schiller Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 3A6FD100019 X-Rspam-User: X-Stat-Signature: tzbo491dai4nhszsswztgzefujebg18x X-Rspamd-Server: rspam03 X-HE-Tag: 1699445793-457732 X-HE-Meta: U2FsdGVkX18JR21Z9L0rUlCGwSGvBW3UxBb7NfT/lVmkKsFQB0IxR59vfq912uIuJdg4y3YHmVEuT9TWPfsTAq3qk2HTlVdOwPjF0jQnt02PFC6tC+nQ/7syX0lQ6YdA38P+TF9ns+QfX89LIbOd3uWswdtSmKSP/LQ3PzTN9Ha3IwexLcQMHZV1MwUnhl82zp3iqh0AobyYMiY014yEqgVZNOT8ugfPb/hBG8z3Q8XqFzPW0j89J0yuWpufeCphRCNnvOc6i9vkw9By5T7OmqxUpMnNZhOmL77+wqf6w76pMbkqAAlkuqBmXlXLXxU0G7Mdl10PfiAFl9tWZ5ncZuTRfuoCvre7X9bvm8R4yAmlisuY9D0lJdQA4FbjJFkrZWqx+rROLf0ZLgN7X8jtSjrLNgxmqTTBzdl/JgN6oCHTwEd2mOg+cgHUtsTXVWjL9my1P5XMy8tHOzVcqjXnXMzkU1MaEyLfYrCYHZpqw9xIE+87Jg969KJehCtbHbYUUXV3JxZMKjXpVyZNHgSZt7N2KRLIc2g7qcPyE0HCwDvgjxF7AL97MIcYW9R94ThS6ytcahi45+qwz9c7U1rVwRQASGfgT8t/9/wXeoX+zmt98Mx4IeHds9qUwLRFyo+pOyUSdYEf5QUkWGfX8TwVsbLhKpYQE7Zj2PAVfKZ0fMPxAYmmwKCM8CE9n7EfLKsl57YLYUWf+3c+eS6VBObEzfkgeQLM0lrjpKMXr492FHUnPs+I/ETtZrN3gMpOnOqfCEVUbUM0g/VpoXcH3Jc4QZkzv+s8k6HbsaKkzOLMR7lHxDPhKrQ1PV/JxjmtigDQo0OM70TtqQz2jAocz75EhZWQj7rdlN4/+jxSdi5JM/2BADX3BjfFR+pmeDolUZaAGx+S7gWYHD21xk8JVKS5U5T+4J+5hBHpQy5BqCY7kHQVGf3G0saMqRB/Qn0CGkxau4uzzL/9W5wXPTEElEM OUYHRBGH S4eeTAc2t5iOgiCbbn9ZwrV9tUwSGRKlenQ70Wa3cznybLpZrDZVKyMHj7wd6oxte01hMyjAhbkm8x/xziw8qRriyIMAUO+ORZkFBuzHnVI0QJNn7HvzbPNfD2rq8du5ODwG7Vsg0Na96zaYEQYLqKsMtyGmCOm04uoe/oabPYVc/k3d/vP390Zo6vtJn1l22AbN5kTZYe+CTy8LjnDnr32Z3Sxzi1E8tfr0jI9AVJOb1htVFmpiEqnMBkal6NLfUzOY8I0S+lrJXb7loTRVYB3CpdgsHqepnl4UgPOWdgYOq/DBWsttXtlw2vL3lep2G7F0ZIVxATxDx46DMVkMT+B4hhjQ8mE8o8g+F6hWh9/5X/Qb7P74yGA3UBA== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On Wed, Nov 8, 2023 at 12:09=E2=80=AFAM Ankur Arora wrote: > > There are broadly three sets of uses of cond_resched(): > > 1. Calls to cond_resched() out of the goodness of our heart, > otherwise known as avoiding lockup splats. > > 2. Open coded variants of cond_resched_lock() which call > cond_resched(). > > 3. Retry or error handling loops, where cond_resched() is used as a > quick alternative to spinning in a tight-loop. > > When running under a full preemption model, the cond_resched() reduces > to a NOP (not even a barrier) so removing it obviously cannot matter. > > But considering only voluntary preemption models (for say code that > has been mostly tested under those), for set-1 and set-2 the > scheduler can now preempt kernel tasks running beyond their time > quanta anywhere they are preemptible() [1]. Which removes any need > for these explicitly placed scheduling points. What about RCU callbacks ? cond_resched() was helping a bit. > > The cond_resched() calls in set-3 are a little more difficult. > To start with, given it's NOP character under full preemption, it > never actually saved us from a tight loop. > With voluntary preemption, it's not a NOP, but it might as well be -- > for most workloads the scheduler does not have an interminable supply > of runnable tasks on the runqueue. > > So, cond_resched() is useful to not get softlockup splats, but not > terribly good for error handling. Ideally, these should be replaced > with some kind of timed or event wait. > For now we use cond_resched_stall(), which tries to schedule if > possible, and executes a cpu_relax() if not. > > Most of the uses here are in set-1 (some right after we give up a > lock or enable bottom-halves, causing an explicit preemption check.) > > We can remove all of them. A patch series of 86 is not reasonable. 596 files changed, 881 insertions(+), 2813 deletions(-) If really cond_resched() becomes a nop (Nice !) , make this at the definition of cond_resched(), and add there nice debugging. Whoever needs to call a "real" cond_resched(), could call a cond_resched_for_real() (Please change the name, this is only to make a point) Then let the removal happen whenever each maintainer decides, 6 months later, without polluting lkml. Imagine we have to revert this series in 1 month, how painful this would be had we removed ~1400 cond_resched() calls all over the place, with many conflicts. Thanks