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 CB429C61D92 for ; Tue, 21 Nov 2023 15:26:51 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 68F486B0482; Tue, 21 Nov 2023 10:26:51 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 6400A6B0483; Tue, 21 Nov 2023 10:26:51 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 52D9A6B0484; Tue, 21 Nov 2023 10:26:51 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 44E326B0482 for ; Tue, 21 Nov 2023 10:26:51 -0500 (EST) Received: from smtpin27.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 195DF1605D4 for ; Tue, 21 Nov 2023 15:26:51 +0000 (UTC) X-FDA: 81482339022.27.F615BD3 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by imf26.hostedemail.com (Postfix) with ESMTP id 209B3140005 for ; Tue, 21 Nov 2023 15:26:48 +0000 (UTC) Authentication-Results: imf26.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=jMWVh0eF; spf=pass (imf26.hostedemail.com: domain of "SRS0=TAUs=HC=paulmck-ThinkPad-P17-Gen-1.home=paulmck@kernel.org" designates 145.40.68.75 as permitted sender) smtp.mailfrom="SRS0=TAUs=HC=paulmck-ThinkPad-P17-Gen-1.home=paulmck@kernel.org"; dmarc=pass (policy=none) header.from=kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1700580409; h=from:from:sender:reply-to: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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=CNU16b9Y7pEFbs9u1138P6rIjPovzamNwLQxM3FBkFg=; b=Zl5ZASYXZPKGwrGv7KTxATvlhGwxGKMaOWQ3gIyHJxz06tL5wmvu/4ibtIg05+q8WFTKC3 XXtwQ9gLIM/wyL5d0Sn2o/QcFLOEeCW+QJQHDaDQRqKbLHbn7DJPsLbcKzD5B19k6KXxUt slO4kIicIV+KsXjsXB2hOwa34yn28Oo= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1700580409; a=rsa-sha256; cv=none; b=uiypJxv28bRZOayJKEA60tFmVKgm0dpcPlrV1bJNsSr4pYjM99x3lhgul8Ro9nop9FzNBO WRLfcZNDJqyALqUfB/Vpbko/9IiAb5dmyA8CW10FkJ6qtkrGKPKzIJIvEY0p/nLyu3DoIy 6soj+hWu54sxtW1cB/jjAMl0qOEeoqk= ARC-Authentication-Results: i=1; imf26.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=jMWVh0eF; spf=pass (imf26.hostedemail.com: domain of "SRS0=TAUs=HC=paulmck-ThinkPad-P17-Gen-1.home=paulmck@kernel.org" designates 145.40.68.75 as permitted sender) smtp.mailfrom="SRS0=TAUs=HC=paulmck-ThinkPad-P17-Gen-1.home=paulmck@kernel.org"; dmarc=pass (policy=none) header.from=kernel.org Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by ams.source.kernel.org (Postfix) with ESMTP id 78C50B8208E; Tue, 21 Nov 2023 15:26:47 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id BF9ABC433C7; Tue, 21 Nov 2023 15:26:46 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1700580406; bh=6ASntq+NzGJvktLNPEkxn4FWCB31PpZ1eITUabEWgKw=; h=Date:From:To:Cc:Subject:Reply-To:References:In-Reply-To:From; b=jMWVh0eFzUUtt7SAyphyKaz8HhM9f+Nkl6I+seXNjiwzoRat6R6hIYirSDEO/6sd3 nvNv6tUy0KjZRU7cP7ws2TZYRtMdrCVV1Mjle7LiN6fQolVBRYzzAHXQtNARBPWJ1K qdKIapd/gf5/yoG4UnK8SRqG2ftnidrY+Z3if7QxznX11tgoks/oX0fJ/nDGGvxHVB 4GHqJtP1AEQb1ssvp2TGQ4IgmsI3EtXheTrUJiJTvvmIcoHdMHZvW244G78TqUcUZj VDD24RpKGqpQrfAn5sKOFh5hK321BioJSfdGWHLD1SnGT5k6roxLFCi2A0FkNphOAw COv/RqmCcCUng== Received: by paulmck-ThinkPad-P17-Gen-1.home (Postfix, from userid 1000) id 5C1E7CE04BD; Tue, 21 Nov 2023 07:26:46 -0800 (PST) Date: Tue, 21 Nov 2023 07:26:46 -0800 From: "Paul E. McKenney" To: Ankur Arora Cc: linux-kernel@vger.kernel.org, tglx@linutronix.de, peterz@infradead.org, torvalds@linux-foundation.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, Julia Lawall , Nicolas Palix Subject: Re: [RFC PATCH 57/86] coccinelle: script to remove cond_resched() Message-ID: <4f028628-3ea2-4f27-add5-27a0a64ed16c@paulmck-laptop> Reply-To: paulmck@kernel.org References: <20231107215742.363031-1-ankur.a.arora@oracle.com> <20231107230822.371443-1-ankur.a.arora@oracle.com> <7d85fbde-fc8d-44b4-802e-376a475891e6@paulmck-laptop> <878r6r3cv0.fsf@oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <878r6r3cv0.fsf@oracle.com> X-Stat-Signature: mk6e8g6hzxbh9iaae6pyk6af3nsi6xsd X-Rspamd-Server: rspam10 X-Rspamd-Queue-Id: 209B3140005 X-Rspam-User: X-HE-Tag: 1700580408-791871 X-HE-Meta: U2FsdGVkX1/ZMzOIBjuKBXFVwMpnBScy/eEjPH6g+0lqRUn4iVXK+kWnzWRdfAfgrvy4KJXDqfAxwGQiaCZNZknX5ODu1HHTmzMu8+1xY/y7GrBtIHKVgvk0dvWNvgOVndIC0THDUyhT9b/cGGKBG8oDii9I8HaQcYYd0f8cnAiQnnYyUOhBrRITBlxuU2oVzLxSUCAKm+9MriJteWj0fUM7hfxBvWAReGyS/N3sgtlbOxWSw3cV0jB+kz5rgE3O8pcSuR5RTMMSwmX8XTD24LvTkNZsMcWhCtg7H3c/KohMTDuqK/P3usE6IauK0N46IhkUV5fTwL3PHVr/ItjereD/iaLFMVSC2uu7R+cf7awzQK1Dhj7S9muzntqrVeMDwyxHgddVCLJmryZJQyyArtAcvfDrMs7pCpN96C2MEhCqgR5AQUOS9WmvCcjv/rlhDFxZDHXTpW1OvLnvC2slLpRQvj3oGGhFRXroMDKQAJbX0gSlUzaOIT+GZuokK/oeit8yUwWIQuCsiqxboQVCOcwd6m3UqldZZLBErD/u6ofdpITFqek9mxVqQx8rS5NpX2haSd1ejkqis0MI+NtBaC0kUctYgTnM7OLZx+7BcjoDwmPqK2id221vvGqrekVVn2au7NtrOufnJnJ22tGGYM5mPnGKednp9R0Z4VlKL6cqJh4LgJ5LmyPC7C7kPOAYJP2yf74fx54TBm+dxf1xDgLz1FVxzel7jofWav48HL6nFEZzhG6x3vlc8Ks2dwroNiTaPPV0REALbgfNopf7BvGBIYjZIqw/YbKOK7jcq4/K/Mkm97qjjpbrd1wXdS/tLSAt8L4O9JhmAoPIZBPxJMm41N3nb8zQyUPOtA6izAGUYDNflY1CloYuh9ub1m7K0tqqItT96f1ItDaLegfi6yXTiXShjF0TmjJPMetrLpUEXTqZeqTshu9ENrEP6Mnk7JcTxSQZB04utCblefR Hk13hCBi xZbaF4XhPN09+kmNbJ0zfQv9cd4pHeTwAV1Nl0uvov/DrZ3SmkgdvagczpHjyx1oTP1ttciGqp/gjoX7gs4JgOkRdI7Z2BTctkgs6D2uJLaiNwxTDjhIgAILaiNBJIJGV23P9kqq57joHY1lHwD/WWe09TAJLHxKgA/+N86rhGEUS0I5mH5HkLazsLczQotss9QPYqAsQvfvQu/m6kADhPI3bkqwvfF+7yM7WF7xy4Gsfa9QRorP3O1Q0FHMAmyi3iDXxewLSFm9mpz31bXFETCB1ve/a6c7LBnZ1L+s1d0ODT9ZMWhJXpd6MY1AOX2KaiKqPVgmRPkOsVLIOQlEdVicrkTPWw/NdqSSlBvsfpf8G1QauvYIUzWxuqHptKIlmLGjno2MSKioFz/4CzjuTLgDQ6fGF1+G5AOnTaKhk1x7EPuvzXyt7lhKMBbHHPz8YANX4LIC1WNC2QJsN8RduvYnnh4BAEuRyL4Nv/ALcZlSEmwzU0k5BBNux3JIre+9YnjaNc3lO99GQzC3KoYODXa22KK0X9KXH/YKzBMXzMBW9CZ0N3itoEnpNAa216NJFsrsRCcmt9s7Xa34IIjeuTvSZYZ3p6tTk+g8nQqn0DSnuMHR/B91fuJ2qDeq+OkuwJepjMnMKBHQ20EQ= 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 Mon, Nov 20, 2023 at 09:16:19PM -0800, Ankur Arora wrote: > > Paul E. McKenney writes: > > > On Tue, Nov 07, 2023 at 03:07:53PM -0800, Ankur Arora wrote: > >> Rudimentary script to remove the straight-forward subset of > >> cond_resched() and allies: > >> > >> 1) if (need_resched()) > >> cond_resched() > >> > >> 2) expression*; > >> cond_resched(); /* or in the reverse order */ > >> > >> 3) if (expression) > >> statement > >> cond_resched(); /* or in the reverse order */ > >> > >> The last two patterns depend on the control flow level to ensure > >> that the complex cond_resched() patterns (ex. conditioned ones) > >> are left alone and we only pick up ones which are only minimally > >> related the neighbouring code. > > > > This series looks to get rid of stall warnings for long in-kernel > > preempt-enabled code paths, which is of course a very good thing. > > But removing all of the cond_resched() calls can actually increase > > scheduling latency compared to the current CONFIG_PREEMPT_NONE=y state, > > correct? > > Not necessarily. > > If TIF_NEED_RESCHED_LAZY is set, then we let the current task finish > before preempting. If that task runs for arbitrarily long (what Thomas > calls the hog problem) -- currently we allow them to run for upto one > extra tick (which might shorten/become a tunable.) Agreed, and that is the easy case. But getting rid of the cond_resched() calls really can increase scheduling latency of this patchset compared to status-quo mainline. > If TIF_NEED_RESCHED is set, then it gets folded the same it does now > and preemption happens at the next safe preemption point. > > So, I guess the scheduling latency would always be bounded but how much > latency a task would incur would be scheduler policy dependent. > > This is early days, so the policy (or really the rest of it) isn't set > in stone but having two levels of preemption -- immediate and > deferred -- does seem to give the scheduler greater freedom of policy. "Give the scheduler freedom!" is a wonderful slogan, but not necessarily a useful one-size-fits-all design principle. The scheduler does not and cannot know everything, after all. > Btw, are you concerned about the scheduling latencies in general or the > scheduling latency of a particular set of tasks? There are a lot of workloads out there with a lot of objective functions and constraints, but it is safe to say that both will be important, as will other things, depending on the workload. But you knew that already, right? ;-) > > If so, it would be good to take a measured approach. For example, it > > is clear that a loop that does a cond_resched() every (say) ten jiffies > > can remove that cond_resched() without penalty, at least in kernels built > > with either CONFIG_NO_HZ_FULL=n or CONFIG_PREEMPT=y. But this is not so > > clear for a loop that does a cond_resched() every (say) ten microseconds. > > True. Though both of those loops sound bad :). Yes, but do they sound bad enough to be useful in the real world? ;-) > Yeah, and as we were discussing offlist, the question is the comparative > density of preempt_dec_and_test() is true vs calls to cond_resched(). > > And if they are similar then we could replace cond_resched() quiescence > reporting with ones in preempt_enable() (as you mention elsewhere in the > thread.) Here is hoping that something like that can help. I am quite happy with the thought of reducing the number of cond_resched() invocations, but not at the expense of the Linux kernel failing to do its job. Thanx, Paul