mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Peter Zijlstra <peterz@infradead.org>
To: Youssef Esmat <youssefesmat@chromium.org>
Cc: LKML <linux-kernel@vger.kernel.org>,
	bsegall@google.com, mingo@kernel.org, vincent.guittot@linaro.org,
	juri.lelli@redhat.com, dietmar.eggemann@arm.com,
	rostedt@goodmis.org, mgorman@suse.de, bristot@redhat.com,
	corbet@lwn.net, qyousef@layalina.io, chris.hyser@oracle.com,
	patrick.bellasi@matbug.net, pjt@google.com, pavel@ucw.cz,
	qperret@google.com, tim.c.chen@linux.intel.com,
	joshdon@google.com, timj@gnu.org, kprateek.nayak@amd.com,
	yu.c.chen@intel.com, joel@joelfernandes.org, efault@gmx.de,
	tglx@linutronix.de, wuyun.abel@bytedance.com
Subject: Re: [PATCH] sched/eevdf: Toggle eligibility through sched_feat
Date: Sun, 15 Oct 2023 12:44:28 +0200	[thread overview]
Message-ID: <20231015104428.GA11840@noisy.programming.kicks-ass.net> (raw)
In-Reply-To: <20231013030213.2472697-1-youssefesmat@chromium.org>

On Thu, Oct 12, 2023 at 10:02:13PM -0500, Youssef Esmat wrote:
> Interactive workloads see performance gains by disabling eligibility
> checks (EEVDF->EVDF). Disabling the checks reduces the number of
> context switches and delays less important work (higher deadlines/nice
> values) in favor of more important work (lower deadlines/nice values).
> 
> That said, that can add large latencies for some work loads and as the
> default is eligibility on, but allowing it to be turned off when
> beneficial.
> 
> Signed-off-by: Youssef Esmat <youssefesmat@chromium.org>
> Link: https://lore.kernel.org/lkml/CA+q576MS0-MV1Oy-eecvmYpvNT3tqxD8syzrpxQ-Zk310hvRbw@mail.gmail.com/
> ---
>  kernel/sched/fair.c     | 3 +++
>  kernel/sched/features.h | 1 +
>  2 files changed, 4 insertions(+)
> 
> diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
> index a751e552f253..16106da5a354 100644
> --- a/kernel/sched/fair.c
> +++ b/kernel/sched/fair.c
> @@ -728,6 +728,9 @@ int entity_eligible(struct cfs_rq *cfs_rq, struct sched_entity *se)
>  	s64 avg = cfs_rq->avg_vruntime;
>  	long load = cfs_rq->avg_load;
>  
> +	if (!sched_feat(ENFORCE_ELIGIBILITY))
> +		return 1;
> +
>  	if (curr && curr->on_rq) {
>  		unsigned long weight = scale_load_down(curr->load.weight);
>  

Right.. could you pretty please try:

  git://git.kernel.org/pub/scm/linux/kernel/git/peterz/queue.git sched/eevdf

as of yesterday or so.

It defaults to (EEVDF relevant features):

SCHED_FEAT(PLACE_LAG, true)
SCHED_FEAT(PLACE_DEADLINE_INITIAL, true)
SCHED_FEAT(PREEMPT_SHORT, true)
SCHED_FEAT(PLACE_SLEEPER, false)
SCHED_FEAT(GENTLE_SLEEPER, true)
SCHED_FEAT(EVDF, false)
SCHED_FEAT(DELAY_DEQUEUE, true)
SCHED_FEAT(GENTLE_DELAY, true)

If that doesn't do well enough, could you please try, in order of
preference:

2) NO_GENTLE_DELAY
3) NO_DELAY_DEQUEUE, PLACE_SLEEPER
4) NO_DELAY_DEQUEUE, PLACE_SLEEPER, NO_GENTLE_SLEEPER

I really don't like the EVDF option, and I think you'll end up
regretting using it sooner rather than later, just to make this one
benchmark you have happy.

I'm hoping the default is enough, but otherwise any of the above should
be a *much* better scheduler.

Also, bonus points if you can create us a stand alone benchmark that
captures your metric (al-la facebook's schbench) without the whole
chrome nonsense, that'd be epic.

  parent reply	other threads:[~2023-10-15 10:45 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-10-13  3:02 Youssef Esmat
2023-10-13  6:50 ` Mike Galbraith
2023-10-15 10:44 ` Peter Zijlstra [this message]
2023-10-16 13:33   ` Tor Vic
2023-10-16 15:28   ` Steven Rostedt
2023-10-16 16:52     ` Peter Zijlstra

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=20231015104428.GA11840@noisy.programming.kicks-ass.net \
    --to=peterz@infradead.org \
    --cc=bristot@redhat.com \
    --cc=bsegall@google.com \
    --cc=chris.hyser@oracle.com \
    --cc=corbet@lwn.net \
    --cc=dietmar.eggemann@arm.com \
    --cc=efault@gmx.de \
    --cc=joel@joelfernandes.org \
    --cc=joshdon@google.com \
    --cc=juri.lelli@redhat.com \
    --cc=kprateek.nayak@amd.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mgorman@suse.de \
    --cc=mingo@kernel.org \
    --cc=patrick.bellasi@matbug.net \
    --cc=pavel@ucw.cz \
    --cc=pjt@google.com \
    --cc=qperret@google.com \
    --cc=qyousef@layalina.io \
    --cc=rostedt@goodmis.org \
    --cc=tglx@linutronix.de \
    --cc=tim.c.chen@linux.intel.com \
    --cc=timj@gnu.org \
    --cc=vincent.guittot@linaro.org \
    --cc=wuyun.abel@bytedance.com \
    --cc=youssefesmat@chromium.org \
    --cc=yu.c.chen@intel.com \
    /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

Powered by JetHome