[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <YVwoy30GY61Z4nid@hirez.programming.kicks-ass.net>
Date: Tue, 5 Oct 2021 12:28:27 +0200
From: Peter Zijlstra <peterz@...radead.org>
To: Vincent Guittot <vincent.guittot@...aro.org>
Cc: Mel Gorman <mgorman@...hsingularity.net>,
Mike Galbraith <efault@....de>, Ingo Molnar <mingo@...nel.org>,
Valentin Schneider <valentin.schneider@....com>,
Aubrey Li <aubrey.li@...ux.intel.com>,
Barry Song <song.bao.hua@...ilicon.com>,
Srikar Dronamraju <srikar@...ux.vnet.ibm.com>,
LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 2/2] sched/fair: Scale wakeup granularity relative to
nr_running
On Wed, Sep 22, 2021 at 08:22:43PM +0200, Vincent Guittot wrote:
> @@ -7161,6 +7162,13 @@ static void check_preempt_wakeup(struct rq *rq,
> struct task_struct *p, int wake_
> return;
>
> update_curr(cfs_rq_of(se));
> + delta_exec = se->sum_exec_runtime - se->prev_sum_exec_runtime;
> + /*
> + * Ensure that current got a chance to move forward
> + */
> + if (delta_exec < sysctl_sched_min_granularity)
> + return;
> +
I think we tried that at some point; IIRC the problem with this is that
if the interactive task fails to preempt, that preemption is lost. IOW
interactivity suffers.
Basically if you don't want wake-up preemptions, use SCHED_BATCH, then
those tasks will not preempt one another, but the SCHED_NORMAL tasks
will preempt them.
Powered by blists - more mailing lists