linux-kernel - Re: [RFC PATCH 0/1] sched/eevdf: Curb wakeup preemption further

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>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date: Fri, 29 Mar 2024 08:46:53 +0530
From: K Prateek Nayak <kprateek.nayak@....com>
To: Madadi Vineeth Reddy <vineethr@...ux.ibm.com>
Cc: Dietmar Eggemann <dietmar.eggemann@....com>,
 Steven Rostedt <rostedt@...dmis.org>, Ben Segall <bsegall@...gle.com>,
 Mel Gorman <mgorman@...e.de>, Daniel Bristot de Oliveira
 <bristot@...hat.com>, Valentin Schneider <vschneid@...hat.com>,
 linux-kernel@...r.kernel.org, Tobias Huschle <huschle@...ux.ibm.com>,
 Luis Machado <luis.machado@....com>, Chen Yu <yu.c.chen@...el.com>,
 Abel Wu <wuyun.abel@...edance.com>, Tianchen Ding
 <dtcccc@...ux.alibaba.com>, Youssef Esmat <youssefesmat@...omium.org>,
 Xuewen Yan <xuewen.yan94@...il.com>,
 "Gautham R. Shenoy" <gautham.shenoy@....com>, Ingo Molnar
 <mingo@...hat.com>, Peter Zijlstra <peterz@...radead.org>,
 Juri Lelli <juri.lelli@...hat.com>,
 Vincent Guittot <vincent.guittot@...aro.org>,
 20240325060226.1540-1-kprateek.nayak@....com
Subject: Re: [RFC PATCH 0/1] sched/eevdf: Curb wakeup preemption further

On 3/28/2024 3:56 PM, Madadi Vineeth Reddy wrote:
> Hi Prateek,
> 
> On 25/03/24 11:32, K Prateek Nayak wrote:
>> Wakeup preemption problem
>> =========================
>>
>> With the curr entity's eligibility check, a wakeup preemption is very
>> likely when an entity with positive lag joins the runqueue pushing the
>> avg_vruntime of the runqueue backwards, making the vruntime of the
>> current entity ineligible. This leads to aggressive wakeup preemption
>> which was previously guarded by wakeup_granularity_ns in legacy CFS.
> 
> Is base_slice_ns not guarding it in EEVDF?

"base_slice_ns" guards it in some sense since lag clamping is based on
the entity's slice but the problem is the eligibility criteria which is
purely based on rq's avg_vruntime and entity's vruntime. Previously
"wakeup_granularity_ns" would have added a buffer before preempting the
current task soon into its run but this is no longer the case with EEVDF
especially if new entities join the runqueue with positive lag pulling
the avg_vruntime backwards.

Please do correct me if I've missed something.

> 
>> Below figure depicts one such aggressive preemption scenario with EEVDF:
> 
> Thanks and Regards
> Madadi Vineeth Reddy

--
Thanks and Regards,
Prateek