From: Kathleen Chang <yt.chang@mediatek.com>
To: Peter Zijlstra <peterz@infradead.org>
Cc: mingo@redhat.com, matthias.bgg@gmail.com,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-mediatek@lists.infradead.org, Jonathan.JMChen@mediatek.com,
wsd_upstream@mediatek.com,
Matt Fleming <matt@codeblueprint.co.uk>,
En-Ron.Chang@mediatek.com
Subject: Re: update vruntime incorrectly When use rt_mutex
Date: Wed, 21 Mar 2018 14:07:57 +0800 [thread overview]
Message-ID: <1521612477.12038.4.camel@mtkswgap22> (raw)
In-Reply-To: <1521611526.11277.2.camel@mtkswgap22>
On Wed, 2018-03-21 at 13:52 +0800, Kathleen Chang wrote:
>
>
> On Fri, 2018-03-16 at 10:51 +0100, Peter Zijlstra wrote:
> > On Thu, Mar 15, 2018 at 03:36:10PM +0800, Kathleen Chang wrote:
> > > hi,
> > >
> > > We found the vruntime might update incorrectly when use rt_mutex.
> >
> > That's nice, on what kernel?
kernel-4.9
> >
> > Also, your email is very hard to make sense of.
> >
> > > <<abnormal case>>
> > > When the Task is waking, update vruntime incorrectly.
> > > 1. When there is a CFS task (A) hold rt_mutex_lock and the state is
> > > TASK_WAKING (on_rq=0), a RT task (B) want to hold this rt_mutex_lock.
> > > Update vruntime incorrectly.
> > >
> > > RT task (B)
> > > rt_mutex_setprio (cfs->RT) -> Task is waking , and update
> > > vruntime
> > >
> > > queued = task_on_rq_queued(p); // task is waking, queued=0
> > > running = task_current(rq, p);
> > > if (queued) /* don't update vruntime here! */
> > > dequeue_task(rq, p, queue_flag);
> > > if (running)
> > > put_prev_task(rq, p);
> > >
> > > check_class_changed(rq, p, prev_class, oldprio); ->
> > > switched_from_fair ->
> > > detach_task_cfs_rq
> > > ( due to task is waking, and bypass
> > > vruntime-=cfs_rq.min_vruntime)
> > >
> > > static void detach_task_cfs_rq(struct task_struct *p)
> > > {
> > > struct sched_entity *se = &p->se;
> > > struct cfs_rq *cfs_rq = cfs_rq_of(se);
> > >
> > > if (!vruntime_normalized(p)) { // return 1, then p->state is
> > > TASK_WAKING
> > > /*
> > > * Fix up our vruntime so that the current sleep doesn't
> > > * cause 'unlimited' sleep bonus.
> > > */
> > > place_entity(cfs_rq, se, 0);
> > > check_vruntime(8, se, cfs_rq->min_vruntime);
> > > se->vruntime -= cfs_rq->min_vruntime;
> >
> > So here we subtract min_vruntime,
>
When the p->state is TASK_WAKING, vruntime_normlized will return 1
and if(!vruntime_normalized(p)) will be 0
in this case, doesn't subtract min_vruntime.
>
>
> >
> > > se->normalized = true;
> >
> > this doesn't exist.. which makes me wonder what you're looking at,
> >
> > > }
> > >
> > > detach_entity_cfs_rq(se);
> > > }
> > >
> > > // when p->state is TASK_WAKING, the task's vruntime is normalized
> > > static inline bool vruntime_normalized(struct task_struct *p)
> > > {
> > > .....
> > > if (!se->sum_exec_runtime || p->state == TASK_WAKING)
> > > return true;
> > >
> > > }
> > >
> > > 2. When the task (A) which holds the rt_muex_lock unlock the
> > > rt_mutex_lock.
> > > Task (A) must be on_rq=1
> > >
> > > rt_mutex_setprio (RT->CFS)
> > > if (queued)
> > > enqueue_task(rq, p, queue_flag); );
> > > /* vruntime += cfs_rq.min_vruntime */
> >
> > And here we're adding min_vruntime.
> >
> > > if (running)
> > > set_curr_task(rq, p);
> > >
> > > that result in vruntime accumulates
> >
> > So what exactly is the problem?
> >
When the p->state is TASK_WAKING, detach_task_cfs_rq doesn't subtract
min_vruntime and adding min_vruntime in enqueue_task,
That result in vruntime accumulates to a extreme large number.
>
>
WARNING: multiple messages have this Message-ID (diff)
From: yt.chang@mediatek.com (Kathleen Chang)
To: linux-arm-kernel@lists.infradead.org
Subject: update vruntime incorrectly When use rt_mutex
Date: Wed, 21 Mar 2018 14:07:57 +0800 [thread overview]
Message-ID: <1521612477.12038.4.camel@mtkswgap22> (raw)
In-Reply-To: <1521611526.11277.2.camel@mtkswgap22>
On Wed, 2018-03-21 at 13:52 +0800, Kathleen Chang wrote:
>
>
> On Fri, 2018-03-16 at 10:51 +0100, Peter Zijlstra wrote:
> > On Thu, Mar 15, 2018 at 03:36:10PM +0800, Kathleen Chang wrote:
> > > hi,
> > >
> > > We found the vruntime might update incorrectly when use rt_mutex.
> >
> > That's nice, on what kernel?
kernel-4.9
> >
> > Also, your email is very hard to make sense of.
> >
> > > <<abnormal case>>
> > > When the Task is waking, update vruntime incorrectly.
> > > 1. When there is a CFS task (A) hold rt_mutex_lock and the state is
> > > TASK_WAKING (on_rq=0), a RT task (B) want to hold this rt_mutex_lock.
> > > Update vruntime incorrectly.
> > >
> > > RT task (B)
> > > rt_mutex_setprio (cfs->RT) -> Task is waking , and update
> > > vruntime
> > >
> > > queued = task_on_rq_queued(p); // task is waking, queued=0
> > > running = task_current(rq, p);
> > > if (queued) /* don't update vruntime here! */
> > > dequeue_task(rq, p, queue_flag);
> > > if (running)
> > > put_prev_task(rq, p);
> > >
> > > check_class_changed(rq, p, prev_class, oldprio); ->
> > > switched_from_fair ->
> > > detach_task_cfs_rq
> > > ( due to task is waking, and bypass
> > > vruntime-=cfs_rq.min_vruntime)
> > >
> > > static void detach_task_cfs_rq(struct task_struct *p)
> > > {
> > > struct sched_entity *se = &p->se;
> > > struct cfs_rq *cfs_rq = cfs_rq_of(se);
> > >
> > > if (!vruntime_normalized(p)) { // return 1, then p->state is
> > > TASK_WAKING
> > > /*
> > > * Fix up our vruntime so that the current sleep doesn't
> > > * cause 'unlimited' sleep bonus.
> > > */
> > > place_entity(cfs_rq, se, 0);
> > > check_vruntime(8, se, cfs_rq->min_vruntime);
> > > se->vruntime -= cfs_rq->min_vruntime;
> >
> > So here we subtract min_vruntime,
>
When the p->state is TASK_WAKING, vruntime_normlized will return 1
and if(!vruntime_normalized(p)) will be 0
in this case, doesn't subtract min_vruntime.
>
>
> >
> > > se->normalized = true;
> >
> > this doesn't exist.. which makes me wonder what you're looking at,
> >
> > > }
> > >
> > > detach_entity_cfs_rq(se);
> > > }
> > >
> > > // when p->state is TASK_WAKING, the task's vruntime is normalized
> > > static inline bool vruntime_normalized(struct task_struct *p)
> > > {
> > > .....
> > > if (!se->sum_exec_runtime || p->state == TASK_WAKING)
> > > return true;
> > >
> > > }
> > >
> > > 2. When the task (A) which holds the rt_muex_lock unlock the
> > > rt_mutex_lock.
> > > Task (A) must be on_rq=1
> > >
> > > rt_mutex_setprio (RT->CFS)
> > > if (queued)
> > > enqueue_task(rq, p, queue_flag); );
> > > /* vruntime += cfs_rq.min_vruntime */
> >
> > And here we're adding min_vruntime.
> >
> > > if (running)
> > > set_curr_task(rq, p);
> > >
> > > that result in vruntime accumulates
> >
> > So what exactly is the problem?
> >
When the p->state is TASK_WAKING, detach_task_cfs_rq doesn't subtract
min_vruntime and adding min_vruntime in enqueue_task,
That result in vruntime accumulates to a extreme large number.
>
>
WARNING: multiple messages have this Message-ID (diff)
From: Kathleen Chang <yt.chang@mediatek.com>
To: Peter Zijlstra <peterz@infradead.org>
Cc: <mingo@redhat.com>, <matthias.bgg@gmail.com>,
<linux-kernel@vger.kernel.org>,
<linux-arm-kernel@lists.infradead.org>,
<linux-mediatek@lists.infradead.org>,
<Jonathan.JMChen@mediatek.com>, <wsd_upstream@mediatek.com>,
Matt Fleming <matt@codeblueprint.co.uk>,
<En-Ron.Chang@mediatek.com>
Subject: Re: update vruntime incorrectly When use rt_mutex
Date: Wed, 21 Mar 2018 14:07:57 +0800 [thread overview]
Message-ID: <1521612477.12038.4.camel@mtkswgap22> (raw)
In-Reply-To: <1521611526.11277.2.camel@mtkswgap22>
On Wed, 2018-03-21 at 13:52 +0800, Kathleen Chang wrote:
>
>
> On Fri, 2018-03-16 at 10:51 +0100, Peter Zijlstra wrote:
> > On Thu, Mar 15, 2018 at 03:36:10PM +0800, Kathleen Chang wrote:
> > > hi,
> > >
> > > We found the vruntime might update incorrectly when use rt_mutex.
> >
> > That's nice, on what kernel?
kernel-4.9
> >
> > Also, your email is very hard to make sense of.
> >
> > > <<abnormal case>>
> > > When the Task is waking, update vruntime incorrectly.
> > > 1. When there is a CFS task (A) hold rt_mutex_lock and the state is
> > > TASK_WAKING (on_rq=0), a RT task (B) want to hold this rt_mutex_lock.
> > > Update vruntime incorrectly.
> > >
> > > RT task (B)
> > > rt_mutex_setprio (cfs->RT) -> Task is waking , and update
> > > vruntime
> > >
> > > queued = task_on_rq_queued(p); // task is waking, queued=0
> > > running = task_current(rq, p);
> > > if (queued) /* don't update vruntime here! */
> > > dequeue_task(rq, p, queue_flag);
> > > if (running)
> > > put_prev_task(rq, p);
> > >
> > > check_class_changed(rq, p, prev_class, oldprio); ->
> > > switched_from_fair ->
> > > detach_task_cfs_rq
> > > ( due to task is waking, and bypass
> > > vruntime-=cfs_rq.min_vruntime)
> > >
> > > static void detach_task_cfs_rq(struct task_struct *p)
> > > {
> > > struct sched_entity *se = &p->se;
> > > struct cfs_rq *cfs_rq = cfs_rq_of(se);
> > >
> > > if (!vruntime_normalized(p)) { // return 1, then p->state is
> > > TASK_WAKING
> > > /*
> > > * Fix up our vruntime so that the current sleep doesn't
> > > * cause 'unlimited' sleep bonus.
> > > */
> > > place_entity(cfs_rq, se, 0);
> > > check_vruntime(8, se, cfs_rq->min_vruntime);
> > > se->vruntime -= cfs_rq->min_vruntime;
> >
> > So here we subtract min_vruntime,
>
When the p->state is TASK_WAKING, vruntime_normlized will return 1
and if(!vruntime_normalized(p)) will be 0
in this case, doesn't subtract min_vruntime.
>
>
> >
> > > se->normalized = true;
> >
> > this doesn't exist.. which makes me wonder what you're looking at,
> >
> > > }
> > >
> > > detach_entity_cfs_rq(se);
> > > }
> > >
> > > // when p->state is TASK_WAKING, the task's vruntime is normalized
> > > static inline bool vruntime_normalized(struct task_struct *p)
> > > {
> > > .....
> > > if (!se->sum_exec_runtime || p->state == TASK_WAKING)
> > > return true;
> > >
> > > }
> > >
> > > 2. When the task (A) which holds the rt_muex_lock unlock the
> > > rt_mutex_lock.
> > > Task (A) must be on_rq=1
> > >
> > > rt_mutex_setprio (RT->CFS)
> > > if (queued)
> > > enqueue_task(rq, p, queue_flag); );
> > > /* vruntime += cfs_rq.min_vruntime */
> >
> > And here we're adding min_vruntime.
> >
> > > if (running)
> > > set_curr_task(rq, p);
> > >
> > > that result in vruntime accumulates
> >
> > So what exactly is the problem?
> >
When the p->state is TASK_WAKING, detach_task_cfs_rq doesn't subtract
min_vruntime and adding min_vruntime in enqueue_task,
That result in vruntime accumulates to a extreme large number.
>
>
next prev parent reply other threads:[~2018-03-21 6:07 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <1521099370.7712.4.camel@mtkswgap22>
2018-03-16 9:51 ` update vruntime incorrectly When use rt_mutex Peter Zijlstra
2018-03-16 9:51 ` Peter Zijlstra
2018-03-16 9:51 ` Peter Zijlstra
2018-03-21 5:52 ` Kathleen Chang
2018-03-21 5:52 ` Kathleen Chang
2018-03-21 5:52 ` Kathleen Chang
2018-03-21 6:07 ` Kathleen Chang [this message]
2018-03-21 6:07 ` Kathleen Chang
2018-03-21 6:07 ` Kathleen Chang
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=1521612477.12038.4.camel@mtkswgap22 \
--to=yt.chang@mediatek.com \
--cc=En-Ron.Chang@mediatek.com \
--cc=Jonathan.JMChen@mediatek.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mediatek@lists.infradead.org \
--cc=matt@codeblueprint.co.uk \
--cc=matthias.bgg@gmail.com \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=wsd_upstream@mediatek.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 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.