linux-kernel - Re: [PATCH V2] sched: Forward deadline for early tick

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

Message-Id: <20250109054852.92163-1-15645113830zzh@gmail.com>
Date: Thu,  9 Jan 2025 13:48:53 +0800
From: zihan zhou <15645113830zzh@...il.com>
To: vincent.guittot@...aro.org
Cc: 15645113830zzh@...il.com,
	bsegall@...gle.com,
	dietmar.eggemann@....com,
	juri.lelli@...hat.com,
	linux-kernel@...r.kernel.org,
	mgorman@...e.de,
	mingo@...hat.com,
	peterz@...radead.org,
	rostedt@...dmis.org,
	vschneid@...hat.com,
	yaowenchao@...com,
	yaozhenguo@...com
Subject: Re: [PATCH V2] sched: Forward deadline for early tick

Thank you for your reply!

> > There are two reasons for tick error: clockevent precision and the
> > CONFIG_IRQ_TIME_ACCOUNTING. with CONFIG_IRQ_TIME_ACCOUNTING every tick
> >  will less than 1ms, but even without it, because of clockevent precision,
> > tick still often less than 1ms. In the system above, there is no such
> >  config, but the task still often takes more than 3ms.
> >
> > To solve this problem, we add a sched feature FORWARD_DEADLINE,
> > consider forwarding the deadline appropriately. When vruntime is very
> > close to the deadline, and the task is ineligible, we consider that task
> >  should be resched, the tolerance is set to min(vslice/128, tick/2).
> 
> I'm worried with this approximation because the task didn't get the
> slice it has requested because of the stolen time by irq or a shorter
> tick duration

Yes, you are right. forward deadline is not a good way, although the error 
is small, the task will have less exec time.

> Yes but it also didn't say that you can move forward its deadline
> before it has consumed its slice request. A task is only ensured to
> get a discrete time quanta but can be preempted after each quanta even
> if its slice has not elapsed.
> 
> What you want, it's to trigger a need_resched after a minimum time
> quanta has elapsed but not to update the deadline before the slice has
> elapsed.
> 
> Now the question is what is the minimum time quanta for us. Should it
> be a tick whatever it's real duration for the task ? Should it be
> longer ?

I have also been thinking about this question: what is the appropriate
 minimum time quanta? I think neither tick nor slice is a good choice.
The task should have an atomic runtime greater than tick to avoid frequent
 switching, but if the time size is silce, it is not flexible, tasks often
use up the requested slice at once without caring about if they are
 eligible. So can we add a new kernel parameter, like 
sysctl_sched_min_granularity? Adding a min_granularity between tick and
 slice seems like a good choice.

We can let a task exec min_granularity time at once, then it is needed to
 consider whether the task is eligible or whether the deadline needs
 to be updated.

But I don't know how to handle wake up preemption more appropriately.
Is it necessary to wait for the preempted task to complete an atomic time?