[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <f97b7506a84e43ea82eb0b947324e835@AcuMS.aculab.com>
Date: Wed, 8 Nov 2023 09:43:10 +0000
From: David Laight <David.Laight@...LAB.COM>
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>,
"richard@....at" <richard@....at>,
"mjguzik@...il.com" <mjguzik@...il.com>
Subject: RE: [RFC PATCH 00/86] Make the kernel preemptible
From: Ankur Arora
> Sent: 07 November 2023 21:57
...
> There are four main sets of preemption points in the kernel:
>
> 1. return to user
> 2. explicit preemption points (cond_resched() and its ilk)
> 3. return to kernel (tick/IPI/irq at irqexit)
> 4. end of non-preemptible sections at (preempt_count() == preempt_offset)
>
...
> Policies:
>
> A - preemption=none: run to completion
> B - preemption=voluntary: run to completion, unless a task of higher
> sched-class awaits
> C - preemption=full: optimized for low-latency. Preempt whenever a higher
> priority task awaits.
If you remove cond_resched() then won't both B and C require an extra IPI.
That is probably OK for RT tasks but could get expensive for
normal tasks that aren't bound to a specific cpu.
I suspect C could also lead to tasks being pre-empted just before
they sleep (eg after waking another task).
There might already be mitigation for that, I'm not sure if
a voluntary sleep can be done in a non-pre-emptible section.
Certainly it should all help the scheduling of RT tasks - which
can currently get delayed by a non-RT task in a slow kernel path.
Although the worst one is the softint code...
David
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)
Powered by blists - more mailing lists