From: Pavan Kondeti <firstname.lastname@example.org>
To: Qais Yousef <email@example.com>
Cc: Ingo Molnar <firstname.lastname@example.org>,
Peter Zijlstra <email@example.com>,
Steven Rostedt <firstname.lastname@example.org>,
Dietmar Eggemann <email@example.com>,
Juri Lelli <firstname.lastname@example.org>,
Vincent Guittot <email@example.com>,
Ben Segall <firstname.lastname@example.org>, Mel Gorman <email@example.com>,
Subject: Re: [PATCH v2 5/6] sched/rt: Better manage pushing unfit tasks on wakeup
Date: Thu, 27 Feb 2020 09:06:08 +0530 [thread overview]
Message-ID: <20200227033608.GN28029@codeaurora.org> (raw)
On Wed, Feb 26, 2020 at 04:02:48PM +0000, Qais Yousef wrote:
> On 02/25/20 09:25, Pavan Kondeti wrote:
> > > I haven't been staring at this code for as long as you, but since we have
> > > logic at wakeup to do a push, I think we need something here anyway for unfit
> > > tasks.
> > >
> > > Fixing select_task_rq_rt() to better balance tasks will help a lot in general,
> > > but if that was enough already then why do we need to consider a push at the
> > > wakeup at all then?
> > >
> > > AFAIU, in SMP the whole push-pull mechanism is racy and we introduce redundancy
> > > at taking the decision on various points to ensure we minimize this racy nature
> > > of SMP systems. Anything could have happened between the time we called
> > > select_task_rq_rt() and the wakeup, so we double check again before we finally
> > > go and run. That's how I interpret it.
> > >
> > > I am open to hear about other alternatives first anyway. Your help has been
> > > much appreciated so far.
> > >
> > The search inside find_lowest_rq() happens without any locks so I believe it
> > is expected to have races like this. In fact there is a comment in the code
> > saying "This test is optimistic, if we get it wrong the load-balancer
> > will have to sort it out" in select_task_rq_rt(). However, the push logic
> > as of today works only for overloaded case. In that sense, your patch fixes
> > this race for b.L systems. At the same time, I feel like tracking nonfit tasks
> > just to fix this race seems to be too much. I will leave this to Steve and
> > others to take a decision.
> I do think without this tasks can end up on the wrong CPU longer than they
> should. Keep in mind that if a task is boosted to run on a big core, it still
> have to compete with non-boosted tasks who can run on a any cpu. So this
> opportunistic push might be necessary.
> For 5.6 though, I'll send an updated series that removes the fitness check from
> task_woken_rt() && switched_to_rt() and carry on with this discussion for 5.7.
> > I thought of suggesting to remove the below check from select_task_rq_rt()
> > p->prio < cpu_rq(target)->rt.highest_prio.curr
> > which would then make the target CPU overloaded and the push logic would
> > spread the tasks. That works for a b.L system too. However there seems to
> > be a very good reason for doing this. see
> > https://lore.kernel.org/patchwork/patch/539137/
> > The fact that a CPU is part of lowest_mask but running a higher prio RT
> > task means there is a race. Should we retry one more time to see if we find
> > another CPU?
> Isn't this what I did in v1?
Yes, that patch allows overloading the CPU When the priorities are same.
I think, We should also consider when a low prio task and high prio task
are waking at the same time and high prio task winning the race.
Qualcomm India Private Limited, on behalf of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project.
next prev parent reply other threads:[~2020-02-27 3:36 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-02-23 18:39 [PATCH v2 0/6] RT Capacity Awareness Fixes & Improvements Qais Yousef
2020-02-23 18:39 ` [PATCH v2 1/6] sched/rt: cpupri_find: implement fallback mechanism for !fit case Qais Yousef
2020-02-23 18:39 ` [PATCH v2 2/6] sched/rt: Re-instate old behavior in select_task_rq_rt Qais Yousef
2020-02-25 15:21 ` Dietmar Eggemann
2020-02-26 11:34 ` Qais Yousef
2020-02-23 18:39 ` [PATCH v2 3/6] sched/rt: Optimize cpupri_find on non-heterogenous systems Qais Yousef
2020-02-23 18:39 ` [PATCH v2 4/6] sched/rt: allow pulling unfitting task Qais Yousef
2020-02-23 18:40 ` [PATCH v2 5/6] sched/rt: Better manage pushing unfit tasks on wakeup Qais Yousef
2020-02-24 6:10 ` Pavan Kondeti
2020-02-24 12:11 ` Qais Yousef
2020-02-24 16:04 ` Pavan Kondeti
2020-02-24 17:41 ` Qais Yousef
2020-02-25 3:55 ` Pavan Kondeti
2020-02-26 16:02 ` Qais Yousef
2020-02-27 3:36 ` Pavan Kondeti [this message]
2020-02-27 10:29 ` Qais Yousef
2020-02-23 18:40 ` [PATCH v2 6/6] sched/rt: Remove unnecessary assignment in inc/dec_rt_migration Qais Yousef
2020-02-23 23:16 ` Dietmar Eggemann
2020-02-24 12:31 ` Qais Yousef
2020-02-24 13:03 ` Dietmar Eggemann
2020-02-24 13:47 ` Qais Yousef
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:
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
* 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;
as well as URLs for NNTP newsgroup(s).