[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20240221163838.780caaa9@gandalf.local.home>
Date: Wed, 21 Feb 2024 16:38:38 -0500
From: Steven Rostedt <rostedt@...dmis.org>
To: Ankur Arora <ankur.a.arora@...cle.com>
Cc: linux-kernel@...r.kernel.org, tglx@...utronix.de, peterz@...radead.org,
torvalds@...ux-foundation.org, paulmck@...nel.org,
akpm@...ux-foundation.org, luto@...nel.org, bp@...en8.de,
dave.hansen@...ux.intel.com, hpa@...or.com, mingo@...hat.com,
juri.lelli@...hat.com, vincent.guittot@...aro.org, willy@...radead.org,
mgorman@...e.de, jpoimboe@...nel.org, mark.rutland@....com,
jgross@...e.com, andrew.cooper3@...rix.com, bristot@...nel.org,
mathieu.desnoyers@...icios.com, geert@...ux-m68k.org,
glaubitz@...sik.fu-berlin.de, anton.ivanov@...bridgegreys.com,
mattst88@...il.com, krypton@...ich-teichert.org, David.Laight@...LAB.COM,
richard@....at, mjguzik@...il.com, jon.grimm@....com, bharata@....com,
raghavendra.kt@....com, boris.ostrovsky@...cle.com, konrad.wilk@...cle.com
Subject: Re: [PATCH 23/30] sched/fair: handle tick expiry under lazy
preemption
On Mon, 12 Feb 2024 21:55:47 -0800
Ankur Arora <ankur.a.arora@...cle.com> wrote:
> The default policy for lazy scheduling is to schedule in exit-to-user,
> assuming that would happen within the remaining time quanta of the
> task.
>
> However, that runs into the 'hog' problem -- the target task might
> be running in the kernel and might not relinquish CPU on its own.
>
> Handle that by upgrading the ignored tif_resched(NR_lazy) bit to
> tif_resched(NR_now) at the next tick.
>
> Cc: Ingo Molnar <mingo@...hat.com>
> Cc: Peter Zijlstra <peterz@...radead.org>
> Cc: Juri Lelli <juri.lelli@...hat.com>
> Cc: Vincent Guittot <vincent.guittot@...aro.org>
> Originally-by: Thomas Gleixner <tglx@...utronix.de>
> Link: https://lore.kernel.org/lkml/87jzshhexi.ffs@tglx/
> Signed-off-by: Ankur Arora <ankur.a.arora@...cle.com>
>
> ---
> Note:
> Instead of special casing the tick, it might be simpler to always
> do the upgrade on the second resched_curr().
>
> The theoretical problem with doing that is that the current
> approach deterministically provides a well-defined extra unit of
> time. Going with a second resched_curr() might mean that the
> amount of extra time the task gets depends on the vagaries of
> the incoming resched_curr() (which is fine if it's mostly from
> the tick; not fine if we could get it due to other reasons.)
>
> Practically, both performed equally well in my tests.
>
> Thoughts?
I personally prefer the determinism of using the tick to force the resched.
-- Steve
Powered by blists - more mailing lists