From: Steven Rostedt <rostedt@goodmis.org>
To: Joel Fernandes <joel@joelfernandes.org>
Cc: Prakash Sangappa <prakash.sangappa@oracle.com>,
Peter Zijlstra <peterz@infradead.org>,
linux-kernel@vger.kernel.org, linux-trace-kernel@vger.kernel.org,
Thomas Gleixner <tglx@linutronix.de>,
Ankur Arora <ankur.a.arora@oracle.com>,
Linus Torvalds <torvalds@linux-foundation.org>,
linux-mm@kvack.org, x86@kernel.org,
Andrew Morton <akpm@linux-foundation.org>,
luto@kernel.org, bp@alien8.de, dave.hansen@linux.intel.com,
hpa@zytor.com, juri.lelli@redhat.com, vincent.guittot@linaro.org,
willy@infradead.org, mgorman@suse.de, jon.grimm@amd.com,
bharata@amd.com, raghavendra.kt@amd.com,
Boris Ostrovsky <boris.ostrovsky@oracle.com>,
Konrad Wilk <konrad.wilk@oracle.com>,
jgross@suse.com, Andrew.Cooper3@citrix.com,
Vineeth Pillai <vineethrp@google.com>,
Suleiman Souhlal <suleiman@google.com>,
Ingo Molnar <mingo@kernel.org>,
Mathieu Desnoyers <mathieu.desnoyers@efficios.com>,
Clark Williams <clark.williams@gmail.com>,
bigeasy@linutronix.de, daniel.wagner@suse.com,
Joseph Salisbury <joseph.salisbury@oracle.com>,
broonie@gmail.com
Subject: Re: [RFC][PATCH 1/2] sched: Extended scheduler time slice
Date: Wed, 5 Feb 2025 08:38:57 -0500 [thread overview]
Message-ID: <20250205083857.3cc06aa7@gandalf.local.home> (raw)
In-Reply-To: <20250205081635.397eacb0@gandalf.local.home>
On Wed, 5 Feb 2025 08:16:35 -0500
Steven Rostedt <rostedt@goodmis.org> wrote:
> Correct. And why I don't think this should be used for RT. It's SCHED_OTHER
> that doesn't have any control of the sched tick, where this hint can help.
Honestly, I don't care that much if it is used on all preemption models,
but I do care if it affects RT tasks. The LAZY flag just happens to let us
know if the next schedule is mandatory or not. NEED_RESCHED_LAZY means,
this schedule is not that important, where as the NEED_RESCHED means it is.
That's why I picked that to decide if the task can get extended or not. Has
nothing to do with the preemption method. The preemption method currently
sets that flag.
Now we could just change when NEED_RESCHED_LAZY is set and this could work
with all preemption methods.
To explain this better. Currently we have:
TYPE | Sched Tick | RT Wakeup |
===========+=======================+======================+
None | NEED_RESCHED_LAZY | NEED_RESCHED_LAZY |
-----------+-----------------------+----------------------+
Voluntary | NEED_RESCHED_LAZY | NEED_RESCHED |
-----------+-----------------------+----------------------+
Full | NEED_RESCHED | NEED_RESCHED |
-----------+-----------------------+----------------------+
Perhaps if we do:
TYPE | Sched Tick | RT Wakeup |
===========+===================================+======================+
None | NEED_RESCHED_LAZY | NEED_RESCHED_LAZY |
-----------+-----------------------------------+----------------------+
Voluntary | NEED_RESCHED_LAZY | NEED_RESCHED |
-----------+-----------------------------------+----------------------+
Full | NEED_RESCHED or NEED_RESCHED_LAZY | NEED_RESCHED |
-----------+-----------------------------------+----------------------+
Where on the scheduler tick, for PREEMPT_FULL (and even PREEMPT_RT), we set
NEED_RESCHED if the task is in the kernel and NEED_RESCHED_LAZY if it is in
user space then this patch will work in all preemption methods. As the LAZY
bit will decide if the task gets extended or not.
That is, any SCHED_OTHER task that is being preempted due to its scheduler
tick can be granted 50us more, regardless of the preemption method.
Now on PREEMPT_NONE, it may even get to preempt a RT task a bit more, but
RT tasks have more to worry about if they are running on a PREEMPT_NONE
system anyway!
-- Steve
next prev parent reply other threads:[~2025-02-05 13:38 UTC|newest]
Thread overview: 66+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-01-31 22:58 [RFC][PATCH 0/2] sched: Extended Scheduler Time Slice revisited Steven Rostedt
2025-01-31 22:58 ` [RFC][PATCH 1/2] sched: Extended scheduler time slice Steven Rostedt
2025-02-01 11:59 ` Peter Zijlstra
2025-02-01 12:47 ` Steven Rostedt
2025-02-01 18:11 ` Peter Zijlstra
2025-02-01 23:06 ` Steven Rostedt
2025-02-03 8:43 ` Peter Zijlstra
2025-02-03 8:53 ` Peter Zijlstra
2025-02-03 16:45 ` Steven Rostedt
2025-02-04 3:28 ` Suleiman Souhlal
2025-02-04 3:57 ` Steven Rostedt
2025-02-04 9:16 ` Peter Zijlstra
2025-02-04 12:51 ` Steven Rostedt
2025-02-04 13:16 ` Steven Rostedt
2025-02-04 15:05 ` Steven Rostedt
2025-02-04 15:30 ` Peter Zijlstra
2025-02-04 16:11 ` Steven Rostedt
2025-02-05 9:07 ` Peter Zijlstra
2025-02-05 13:10 ` Steven Rostedt
2025-02-05 13:44 ` Steven Rostedt
2025-02-04 22:44 ` Prakash Sangappa
2025-02-05 0:56 ` Joel Fernandes
2025-02-05 3:04 ` Steven Rostedt
2025-02-05 5:09 ` Joel Fernandes
2025-02-05 13:16 ` Steven Rostedt
2025-02-05 13:38 ` Steven Rostedt [this message]
2025-02-05 21:08 ` Prakash Sangappa
2025-02-05 21:19 ` Steven Rostedt
2025-02-05 21:33 ` Steven Rostedt
2025-02-05 21:36 ` Prakash Sangappa
2025-02-06 3:07 ` Joel Fernandes
2025-02-06 13:30 ` Steven Rostedt
2025-02-06 13:44 ` Sebastian Andrzej Siewior
2025-02-06 13:48 ` Peter Zijlstra
2025-02-06 13:53 ` Sebastian Andrzej Siewior
2025-02-06 13:57 ` Peter Zijlstra
2025-02-06 14:20 ` Steven Rostedt
2025-02-06 14:22 ` Sebastian Andrzej Siewior
2025-02-06 14:27 ` Peter Zijlstra
2025-02-06 14:57 ` Steven Rostedt
2025-02-06 15:01 ` Sebastian Andrzej Siewior
2025-02-10 19:43 ` Steven Rostedt
2025-02-10 22:04 ` David Laight
2025-02-10 22:15 ` Steven Rostedt
2025-02-11 8:21 ` Sebastian Andrzej Siewior
2025-02-11 10:57 ` Peter Zijlstra
2025-02-11 15:28 ` Steven Rostedt
2025-02-12 12:11 ` Sebastian Andrzej Siewior
2025-02-12 15:00 ` Steven Rostedt
2025-02-12 15:18 ` Sebastian Andrzej Siewior
2025-02-10 14:07 ` Joel Fernandes
2025-02-10 19:48 ` Steven Rostedt
2025-02-10 17:20 ` David Laight
2025-02-10 17:27 ` Steven Rostedt
2025-02-10 19:44 ` Steven Rostedt
2025-02-10 21:51 ` David Laight
2025-02-10 21:58 ` Steven Rostedt
2025-02-01 14:35 ` Mathieu Desnoyers
2025-02-01 23:08 ` Steven Rostedt
2025-02-01 23:18 ` Linus Torvalds
2025-02-01 23:35 ` Linus Torvalds
2025-02-02 3:26 ` Steven Rostedt
2025-02-02 3:22 ` Steven Rostedt
2025-02-02 7:22 ` Matthew Wilcox
2025-02-02 22:29 ` Steven Rostedt
2025-01-31 22:58 ` [RFC][PATCH 2/2] sched: Shorten time that tasks can extend their time slice for Steven Rostedt
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20250205083857.3cc06aa7@gandalf.local.home \
--to=rostedt@goodmis.org \
--cc=Andrew.Cooper3@citrix.com \
--cc=akpm@linux-foundation.org \
--cc=ankur.a.arora@oracle.com \
--cc=bharata@amd.com \
--cc=bigeasy@linutronix.de \
--cc=boris.ostrovsky@oracle.com \
--cc=bp@alien8.de \
--cc=broonie@gmail.com \
--cc=clark.williams@gmail.com \
--cc=daniel.wagner@suse.com \
--cc=dave.hansen@linux.intel.com \
--cc=hpa@zytor.com \
--cc=jgross@suse.com \
--cc=joel@joelfernandes.org \
--cc=jon.grimm@amd.com \
--cc=joseph.salisbury@oracle.com \
--cc=juri.lelli@redhat.com \
--cc=konrad.wilk@oracle.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-trace-kernel@vger.kernel.org \
--cc=luto@kernel.org \
--cc=mathieu.desnoyers@efficios.com \
--cc=mgorman@suse.de \
--cc=mingo@kernel.org \
--cc=peterz@infradead.org \
--cc=prakash.sangappa@oracle.com \
--cc=raghavendra.kt@amd.com \
--cc=suleiman@google.com \
--cc=tglx@linutronix.de \
--cc=torvalds@linux-foundation.org \
--cc=vincent.guittot@linaro.org \
--cc=vineethrp@google.com \
--cc=willy@infradead.org \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox