Message-ID: <739dd8ac-cbc9-434d-9726-584ccdf83afb@alliedtelesis.co.nz>
Date:   Wed, 8 Nov 2023 00:48:57 +0000
From:   Chris Packham <Chris.Packham@...iedtelesis.co.nz>
To:     Ankur Arora <ankur.a.arora@...cle.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
CC:     "tglx@...utronix.de" <tglx@...utronix.de>,
        "peterz@...radead.org" <peterz@...radead.org>,
        "torvalds@...ux-foundation.org" <torvalds@...ux-foundation.org>,
        "paulmck@...nel.org" <paulmck@...nel.org>,
        "linux-mm@...ck.org" <linux-mm@...ck.org>,
        "x86@...nel.org" <x86@...nel.org>,
        "akpm@...ux-foundation.org" <akpm@...ux-foundation.org>,
        "luto@...nel.org" <luto@...nel.org>, "bp@...en8.de" <bp@...en8.de>,
        "dave.hansen@...ux.intel.com" <dave.hansen@...ux.intel.com>,
        "hpa@...or.com" <hpa@...or.com>,
        "mingo@...hat.com" <mingo@...hat.com>,
        "juri.lelli@...hat.com" <juri.lelli@...hat.com>,
        "vincent.guittot@...aro.org" <vincent.guittot@...aro.org>,
        "willy@...radead.org" <willy@...radead.org>,
        "mgorman@...e.de" <mgorman@...e.de>,
        "jon.grimm@....com" <jon.grimm@....com>,
        "bharata@....com" <bharata@....com>,
        "raghavendra.kt@....com" <raghavendra.kt@....com>,
        "boris.ostrovsky@...cle.com" <boris.ostrovsky@...cle.com>,
        "konrad.wilk@...cle.com" <konrad.wilk@...cle.com>,
        "jgross@...e.com" <jgross@...e.com>,
        "andrew.cooper3@...rix.com" <andrew.cooper3@...rix.com>,
        "mingo@...nel.org" <mingo@...nel.org>,
        "bristot@...nel.org" <bristot@...nel.org>,
        "mathieu.desnoyers@...icios.com" <mathieu.desnoyers@...icios.com>,
        "geert@...ux-m68k.org" <geert@...ux-m68k.org>,
        "glaubitz@...sik.fu-berlin.de" <glaubitz@...sik.fu-berlin.de>,
        "anton.ivanov@...bridgegreys.com" <anton.ivanov@...bridgegreys.com>,
        "mattst88@...il.com" <mattst88@...il.com>,
        "krypton@...ich-teichert.org" <krypton@...ich-teichert.org>,
        "rostedt@...dmis.org" <rostedt@...dmis.org>,
        "David.Laight@...LAB.COM" <David.Laight@...LAB.COM>,
        "richard@....at" <richard@....at>,
        "mjguzik@...il.com" <mjguzik@...il.com>,
        Oded Gabbay <ogabbay@...nel.org>,
        Miguel Ojeda <ojeda@...nel.org>, Jens Axboe <axboe@...nel.dk>,
        Minchan Kim <minchan@...nel.org>,
        Sergey Senozhatsky <senozhatsky@...omium.org>,
        "Sudip Mukherjee" <sudipm.mukherjee@...il.com>,
        Theodore Ts'o <tytso@....edu>,
        "Jason A. Donenfeld" <Jason@...c4.com>,
        Amit Shah <amit@...nel.org>, Gonglei <arei.gonglei@...wei.com>,
        "Michael S. Tsirkin" <mst@...hat.com>,
        Jason Wang <jasowang@...hat.com>,
        "David S. Miller" <davem@...emloft.net>,
        "Davidlohr Bueso" <dave@...olabs.net>,
        Jonathan Cameron <jonathan.cameron@...wei.com>,
        Dave Jiang <dave.jiang@...el.com>,
        Alison Schofield <alison.schofield@...el.com>,
        Vishal Verma <vishal.l.verma@...el.com>,
        "Ira Weiny" <ira.weiny@...el.com>,
        Dan Williams <dan.j.williams@...el.com>,
        "Sumit Semwal" <sumit.semwal@...aro.org>,
        Christian König <christian.koenig@....com>,
        Andi Shyti <andi.shyti@...nel.org>,
        Ray Jui <rjui@...adcom.com>,
        Scott Branden <sbranden@...adcom.com>,
        Shawn Guo <shawnguo@...nel.org>,
        Sascha Hauer <s.hauer@...gutronix.de>,
        Junxian Huang <huangjunxian6@...ilicon.com>,
        Dmitry Torokhov <dmitry.torokhov@...il.com>,
        Will Deacon <will@...nel.org>, Joerg Roedel <joro@...tes.org>,
        "Mauro Carvalho Chehab" <mchehab@...nel.org>,
        Srinivas Pandruvada <srinivas.pandruvada@...ux.intel.com>,
        Hans de Goede <hdegoede@...hat.com>,
        Ilpo Järvinen <ilpo.jarvinen@...ux.intel.com>,
        Mark Gross <markgross@...nel.org>,
        Finn Thain <fthain@...ux-m68k.org>,
        Michael Schmitz <schmitzmic@...il.com>,
        "James E.J. Bottomley" <jejb@...ux.ibm.com>,
        "Martin K. Petersen" <martin.petersen@...cle.com>,
        Kashyap Desai <kashyap.desai@...adcom.com>,
        Sumit Saxena <sumit.saxena@...adcom.com>,
        Shivasharan S <shivasharan.srikanteshwara@...adcom.com>,
        Mark Brown <broonie@...nel.org>,
        Neil Armstrong <neil.armstrong@...aro.org>,
        "Jens Wiklander" <jens.wiklander@...aro.org>,
        Alex Williamson <alex.williamson@...hat.com>,
        Helge Deller <deller@....de>,
        David Hildenbrand <david@...hat.com>
Subject: Re: [RFC PATCH 85/86] treewide: drivers: remove cond_resched()


On 8/11/23 12:08, 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.
>
> 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.
>
> The cond_resched() calls here are all kinds. Those from set-1
> or set-2 are quite straight-forward to handle.
>
> There are quite a few from set-3, where as noted above, we
> use cond_resched() as if it were a amulent. Which I supppose
> it is, in that it wards off softlockup or RCU splats.
>
> Those are now cond_resched_stall(), but in most cases, given
> that the timeouts are in milliseconds, they could be easily
> timed waits.

For i2c-mpc.c:

It looks as the code in question could probably be converted to 
readb_poll_timeout(). If I find sufficient round-tuits I might look at 
that. Regardless in the context of the tree-wide change ...

Reviewed-by: Chris Packham <chris.packham@...iedtelesis.co.nz>

Powered by blists - more mailing lists