LKML Archive on lore.kernel.org help / color / mirror / Atom feed
From: Vincent Guittot <vincent.guittot@linaro.org> To: Peter Zijlstra <peterz@infradead.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:56:57 +0200 [thread overview] Message-ID: <CAKfTPtB5gjvF8Gx3BSkOJZ+VVUj_2+yJfSB9tVH8iuEby60kvQ@mail.gmail.com> (raw) In-Reply-To: <YRpfdWwJL34PjgI1@hirez.programming.kicks-ass.net> On Mon, 16 Aug 2021 at 14:52, Peter Zijlstra <peterz@infradead.org> wrote: > > 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. That was my point too > > > 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 > > >
next prev parent reply other threads:[~2021-08-16 12:57 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 2021-08-16 12:56 ` Vincent Guittot [this message] 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=CAKfTPtB5gjvF8Gx3BSkOJZ+VVUj_2+yJfSB9tVH8iuEby60kvQ@mail.gmail.com \ --to=vincent.guittot@linaro.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=peterz@infradead.org \ --cc=pjt@google.com \ --cc=riel@surriel.com \ --cc=rostedt@goodmis.org \ --cc=steven.sistare@oracle.com \ --cc=tj@kernel.org \ --cc=viresh.kumar@linaro.org \ /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: linkBe 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; as well as URLs for NNTP newsgroup(s).