mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Vishal Chourasia <vishalc@linux.ibm.com>
To: peterz@infradead.org, mingo@kernel.org, linux-kernel@vger.kernel.org
Subject: Question about DOUBLE_TICK's role alongside EEVDF
Date: Fri, 23 Feb 2024 17:25:22 +0530	[thread overview]
Message-ID: <0818a331-cea3-4962-88ad-09bccbd3659d@linux.ibm.com> (raw)

Hi,

I hope you're doing well. I've been looking into some recent changes in the
scheduler code and would like to get your perspective on a few things.

I was examining commit 5e963f2bd465 ("sched/fair: Commit to EEVDF"), which
removed the check_preempt_tick method. As a result, the DOUBLE_TICK feature used
within the entity_tick function no longer seems to directly influence scheduling
decisions. I understand that this feature was designed to handle interactions
between periodic ticks and the high-resolution timer (hrtick).

Here's my understanding so far (please correct me if there are any inaccuracies):

DOUBLE_TICK: Enabled periodic ticks to proceed even when an hrtick timer was
active, potentially canceling the hrtick timer in __schedule if active.

Commit 5e963f2bd465: Removed a key decision point where DOUBLE_TICK played a
role, making its current utility questionable.

This brings me to my main question: As we transition towards EEVDF for
calculating preemption points(based on entity lag) and the scheduler manages
resource allocation in quanta, is there a continued need for the hrtick timer?

In the case of multiple processes with different nice values, EEVDF handles
their preemption according to their lag. However, the exact behavior depends on
the values of base_slice_ns and config_hz.

It's possible I don't have all the pieces of the puzzle, so my question might
not make sense. But I wanted to bring forth this point. It would be great to
know your thoughts.

Thank you for your time.

-- vishal.c


diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index 533547e3c90a..73e1372d1a0d 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -5510,12 +5510,6 @@ entity_tick(struct cfs_rq *cfs_rq, struct sched_entity
*curr, int queued)
                resched_curr(rq_of(cfs_rq));
                return;
        }
-       /*
-        * don't let the period tick interfere with the hrtick preemption
-        */
-       if (!sched_feat(DOUBLE_TICK) &&
-                       hrtimer_active(&rq_of(cfs_rq)->hrtick_timer))
-               return;
 #endif
 }

                 reply	other threads:[~2024-02-23 11:55 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

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=0818a331-cea3-4962-88ad-09bccbd3659d@linux.ibm.com \
    --to=vishalc@linux.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@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®