linux-kernel - Question about DOUBLE_TICK's role alongside EEVDF

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Message-ID: <0818a331-cea3-4962-88ad-09bccbd3659d@linux.ibm.com>
Date: Fri, 23 Feb 2024 17:25:22 +0530
From: Vishal Chourasia <vishalc@...ux.ibm.com>
To: peterz@...radead.org, mingo@...nel.org, linux-kernel@...r.kernel.org
Subject: Question about DOUBLE_TICK's role alongside EEVDF

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
 }