[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20250502143544.GW4439@noisy.programming.kicks-ass.net>
Date: Fri, 2 May 2025 16:35:44 +0200
From: Peter Zijlstra <peterz@...radead.org>
To: Sebastian Andrzej Siewior <bigeasy@...utronix.de>
Cc: Prakash Sangappa <prakash.sangappa@...cle.com>,
linux-kernel@...r.kernel.org, rostedt@...dmis.org,
mathieu.desnoyers@...icios.com, tglx@...utronix.de,
kprateek.nayak@....com
Subject: Re: [PATCH V3 1/4] Sched: Scheduler time slice extension
On Fri, May 02, 2025 at 02:34:33PM +0200, Sebastian Andrzej Siewior wrote:
> On 2025-05-02 01:59:52 [+0000], Prakash Sangappa wrote:
> > diff --git a/kernel/entry/common.c b/kernel/entry/common.c
> > index 20154572ede9..b26adccb32df 100644
> > --- a/kernel/entry/common.c
> > +++ b/kernel/entry/common.c
> > @@ -98,8 +99,12 @@ __always_inline unsigned long exit_to_user_mode_loop(struct pt_regs *regs,
> >
> > local_irq_enable_exit_to_user(ti_work);
> >
> > - if (ti_work & (_TIF_NEED_RESCHED | _TIF_NEED_RESCHED_LAZY))
> > - schedule();
> > + if (ti_work & (_TIF_NEED_RESCHED | _TIF_NEED_RESCHED_LAZY)) {
>
> I asked to limit this to LAZY only.
No -- this should work irrespective of the preemption model chosen.
It should also have a default time that is shorter than the scheduling
delay normally observed.
It should probably also have a PR_WARN on raising the sysctl value.
I know you worry about RT, but show me a trace where it is a problem.
Powered by blists - more mailing lists