From: Vishal Chourasia <vishalc@linux.ibm.com>
To: peterz@infradead.org, linux-kernel@vger.kernel.org
Cc: Vishal Chourasia <vishalc@linux.ibm.com>
Subject: [RFC 0/1] sched: Deprecate DOUBLE_TICK feature
Date: Fri, 8 Mar 2024 10:53:03 +0530 [thread overview]
Message-ID: <20240308052304.1835792-1-vishalc@linux.ibm.com> (raw)
Upon examining commit 5e963f2bd465, titled "sched/fair: Commit to EEVDF,"
it was noted that the method check_preempt_tick was removed. This change
has rendered the DOUBLE_TICK feature, which previously played a role within
the entity_tick function, inconsequential in the scheduling decisions.
Historically, DOUBLE_TICK enabled periodic ticks to proceed even when a
high-resolution timer (hrtick) was active, with the potential to cancel
the hrtick timer in __schedule if it was active.
With the removal of decision point where DOUBLE_TICK played a role by
commit 5e963f2bd465, questions arise regarding its current utility.
The discussion centers on whether there is a continued need for the hrtick
timer as the system transitions towards EEVDF for calculating preemption
points, based on entity lag, and as the scheduler manages resource allocation
in quanta. Particularly, in scenarios involving multiple processes with
different nice values, where EEVDF governs their preemption according to
their lag, however the behavior depends on the specific values of base_slice_ns
and config_hz.
Link: https://lore.kernel.org/lkml/0818a331-cea3-4962-88ad-09bccbd3659d@linux.ibm.com/
Vishal Chourasia (1):
sched: Deprecate DOUBLE_TICK feature
kernel/sched/fair.c | 6 ------
kernel/sched/features.h | 1 -
2 files changed, 7 deletions(-)
--
2.43.0
next reply other threads:[~2024-03-08 5:23 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-03-08 5:23 Vishal Chourasia [this message]
2024-03-08 5:23 ` [RFC 1/1] " Vishal Chourasia
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=20240308052304.1835792-1-vishalc@linux.ibm.com \
--to=vishalc@linux.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=peterz@infradead.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
all inboxes | Powered by JetHome®