LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Peter Zijlstra <peterz@infradead.org>
To: Vincent Guittot <vincent.guittot@linaro.org>
Cc: Josh Don <joshdon@google.com>, Ingo Molnar <mingo@redhat.com>,
	Juri Lelli <juri.lelli@redhat.com>,
	Dietmar Eggemann <dietmar.eggemann@arm.com>,
	Steven Rostedt <rostedt@goodmis.org>,
	Ben Segall <bsegall@google.com>, Mel Gorman <mgorman@suse.de>,
	Daniel Bristot de Oliveira <bristot@redhat.com>,
	Paul Turner <pjt@google.com>, Oleg Rombakh <olegrom@google.com>,
	Viresh Kumar <viresh.kumar@linaro.org>,
	Steve Sistare <steven.sistare@oracle.com>,
	Tejun Heo <tj@kernel.org>, Rik van Riel <riel@surriel.com>,
	linux-kernel <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 2/2] sched: adjust SCHED_IDLE interactions
Date: Mon, 16 Aug 2021 14:52:05 +0200	[thread overview]
Message-ID: <YRpfdWwJL34PjgI1@hirez.programming.kicks-ass.net> (raw)
In-Reply-To: <CAKfTPtCTjhpkYz_eVr0LxcJavh__KHn2zOudD=QB5gKYZK8DtQ@mail.gmail.com>

On Wed, Aug 11, 2021 at 03:31:49PM +0200, Vincent Guittot wrote:
> On Fri, 30 Jul 2021 at 04:00, Josh Don <joshdon@google.com> wrote:


> > @@ -4216,7 +4228,15 @@ place_entity(struct cfs_rq *cfs_rq, struct sched_entity *se, int initial)
> >                 if (sched_feat(GENTLE_FAIR_SLEEPERS))
> >                         thresh >>= 1;
> >
> > -               vruntime -= thresh;
> > +               /*
> > +                * Don't give sleep credit to a SCHED_IDLE entity if we're
> > +                * placing it onto a cfs_rq with non SCHED_IDLE entities.
> > +                */
> > +               if (!se_is_idle(se) ||
> > +                   cfs_rq->h_nr_running == cfs_rq->idle_h_nr_running)

I really dislike that second clause, either never do this for idle or
always, but not sometimes when the planets are aligned just right.

> Can't this condition above create unfairness between idle entities ?
> idle thread 1 wake up while normal thread is running
> normal thread thread sleeps immediately after
> idle thread 2 wakes up just after and gets some credits compared to the 1st one.

No. Strictly speaking cfs is unfair here. But it's a really tricky case.

Consider a task that is running 50% competing against a task that's
running 100%. What's fair in that situation, a 50/50 split, or a 25/75
split? What if that 50% is 50% of a minute?

What we do here is fudge the vruntime such that we end up with a 50/50
split provided the period over which it blocks is less than a slice.
After that it gradually converges to the 'expected' 25/75 split that
results from strict runnable competition.

By not letting idle tasks participate in this, we avoid idle tasks
'stealing' the !runnable time and they revert back to strict runnable
competition only.

> > +                       vruntime -= thresh;
> > +               else
> > +                       vruntime += 1;
> >         }
> >
> >         /* ensure we never gain time by being placed backwards. */
> > --
> > 2.32.0.554.ge1b32706d8-goog
> >

  parent reply	other threads:[~2021-08-16 12:52 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-07-30  2:00 [PATCH v2 0/2] SCHED_IDLE extensions Josh Don
2021-07-30  2:00 ` [PATCH v2 1/2] sched: cgroup SCHED_IDLE support Josh Don
2021-08-03  2:14   ` jun qian
2021-08-03 20:37     ` Josh Don
2021-08-05 10:18   ` Peter Zijlstra
2021-08-05 17:13     ` Tejun Heo
2021-08-05 23:54       ` Josh Don
2021-08-11 13:48   ` Vincent Guittot
2021-08-23  9:26   ` [tip: sched/core] sched: Cgroup " tip-bot2 for Josh Don
2021-07-30  2:00 ` [PATCH 2/2] sched: adjust SCHED_IDLE interactions Josh Don
2021-08-11 13:31   ` Vincent Guittot
2021-08-12 21:09     ` Josh Don
2021-08-13 12:43       ` Vincent Guittot
2021-08-13 23:55         ` Josh Don
2021-08-16 12:31       ` Peter Zijlstra
2021-08-17 23:48         ` Josh Don
2021-08-16 12:52     ` Peter Zijlstra [this message]
2021-08-16 12:56       ` Vincent Guittot
2021-08-17 23:40       ` Josh Don
2021-08-16 12:31   ` 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=YRpfdWwJL34PjgI1@hirez.programming.kicks-ass.net \
    --to=peterz@infradead.org \
    --cc=bristot@redhat.com \
    --cc=bsegall@google.com \
    --cc=dietmar.eggemann@arm.com \
    --cc=joshdon@google.com \
    --cc=juri.lelli@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mgorman@suse.de \
    --cc=mingo@redhat.com \
    --cc=olegrom@google.com \
    --cc=pjt@google.com \
    --cc=riel@surriel.com \
    --cc=rostedt@goodmis.org \
    --cc=steven.sistare@oracle.com \
    --cc=tj@kernel.org \
    --cc=vincent.guittot@linaro.org \
    --cc=viresh.kumar@linaro.org \
    --subject='Re: [PATCH 2/2] sched: adjust SCHED_IDLE interactions' \
    /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

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).