[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <3ad1798407144171b3e82e90d6b0565c@AcuMS.aculab.com>
Date: Thu, 9 Nov 2023 09:39:33 +0000
From: David Laight <David.Laight@...LAB.COM>
To: 'Steven Rostedt' <rostedt@...dmis.org>,
Kees Cook <keescook@...omium.org>
CC: Ankur Arora <ankur.a.arora@...cle.com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"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>,
"richard@....at" <richard@....at>,
"mjguzik@...il.com" <mjguzik@...il.com>,
Herbert Xu <herbert@...dor.apana.org.au>,
"David S. Miller" <davem@...emloft.net>,
"Eric Dumazet" <edumazet@...gle.com>,
Jakub Kicinski <kuba@...nel.org>,
Paolo Abeni <pabeni@...hat.com>, Thomas Graf <tgraf@...g.ch>
Subject: RE: [RFC PATCH 71/86] treewide: lib: remove cond_resched()
From: Steven Rostedt
> Sent: 08 November 2023 19:42
>
> On Wed, 8 Nov 2023 11:15:37 -0800
> Kees Cook <keescook@...omium.org> wrote:
>
> > FOr the memcpy_kunit.c cases, I don't think there are preemption
> > locations in its loops. Perhaps I'm misunderstanding something? Why will
> > the memcpy test no longer produce softlockup splats?
>
> This patchset will switch over to a NEED_RESCHED_LAZY routine, so that
> VOLUNTARY and NONE preemption models will be forced to preempt if its in
> the kernel for too long.
>
> Time slice is over: set NEED_RESCHED_LAZY
>
> For VOLUNTARY and NONE, NEED_RESCHED_LAZY will not preempt the kernel (but
> will preempt user space).
>
> If in the kernel for over 1 tick (1ms for 1000Hz, 4ms for 250Hz, etc),
> if NEED_RESCHED_LAZY is still set after one tick, then set NEED_RESCHED.
Delaying the reschedule that long seems like a regression.
I'm sure a lot of the cond_resched() calls were added to cause
pre-emption much earlier than 1 tick.
I doubt the distibutions will change from VOLUTARY any time soon.
So that is what most people will be using.
David.
>
> NEED_RESCHED will now schedule in the kernel once it is able to regardless
> of preemption model. (PREEMPT_NONE will now use preempt_disable()).
>
> This allows us to get rid of all cond_resched()s throughout the kernel as
> this will be the new mechanism to keep from running inside the kernel for
> too long. The watchdog is always longer than one tick.
>
> -- Steve
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)
Powered by blists - more mailing lists