From: chenqiwu <qiwuchen55@gmail.com>
To: Vincent Guittot <vincent.guittot@linaro.org>
Cc: Ingo Molnar <mingo@redhat.com>,
Peter Zijlstra <peterz@infradead.org>,
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>,
linux-kernel <linux-kernel@vger.kernel.org>,
chenqiwu <chenqiwu@xiaomi.com>
Subject: Re: [PATCH] sched/fair: add !se->on_rq check before dequeue entity
Date: Thu, 20 Feb 2020 18:09:15 +0800 [thread overview]
Message-ID: <20200220100915.GA14721@cqw-OptiPlex-7050> (raw)
In-Reply-To: <CAKfTPtDzb9XD5wrMhcvGn+dz27nh58taDrdp36YHKNusp739Og@mail.gmail.com>
On Thu, Feb 20, 2020 at 10:38:02AM +0100, Vincent Guittot wrote:
> On Thu, 20 Feb 2020 at 08:29, <qiwuchen55@gmail.com> wrote:
> >
> > From: chenqiwu <chenqiwu@xiaomi.com>
> >
> > We igonre checking for !se->on_rq condition before dequeue one
> > entity from cfs rq. It must be required in case the entity has
> > been dequeued.
>
> Do you have a use case that triggers this situation ?
>
> This is the only way to reach this situation seems to be dequeuing a
> task on a throttled cfs_rq
>
Sorry, I have no use case triggers this situation. It's just found by
reading code.
I agree the situation you mentioned above may have a racy with
dequeue_task_fair() in the following code path:
__schedule
pick_next_task_fair
put_prev_entity
check_cfs_rq_runtime
throttle_cfs_rq
dequeue_entity
So this check is worth to be added for dequeue_task_fair().
next prev parent reply other threads:[~2020-02-20 10:09 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-02-20 7:29 [PATCH] sched/fair: add !se->on_rq check before dequeue entity qiwuchen55
2020-02-20 9:38 ` Vincent Guittot
2020-02-20 10:09 ` chenqiwu [this message]
2020-02-20 10:31 ` Vincent Guittot
2020-02-20 12:15 ` Vincent Guittot
2020-02-20 14:42 ` chenqiwu
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=20200220100915.GA14721@cqw-OptiPlex-7050 \
--to=qiwuchen55@gmail.com \
--cc=bsegall@google.com \
--cc=chenqiwu@xiaomi.com \
--cc=dietmar.eggemann@arm.com \
--cc=juri.lelli@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mgorman@suse.de \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=rostedt@goodmis.org \
--cc=vincent.guittot@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: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.