From: Paul Turner <pjt@google.com>
To: Hidetoshi Seto <seto.hidetoshi@jp.fujitsu.com>
Cc: Xiao Guangrong <xiaoguangrong@cn.fujitsu.com>,
LKML <linux-kernel@vger.kernel.org>,
Peter Zijlstra <a.p.zijlstra@chello.nl>,
Bharata B Rao <bharata@linux.vnet.ibm.com>,
Dhaval Giani <dhaval.giani@gmail.com>,
Balbir Singh <balbir@linux.vnet.ibm.com>,
Vaidyanathan Srinivasan <svaidy@linux.vnet.ibm.com>,
Srivatsa Vaddagiri <vatsa@in.ibm.com>,
Kamalesh Babulal <kamalesh@linux.vnet.ibm.com>,
Ingo Molnar <mingo@elte.hu>, Pavel Emelyanov <xemul@openvz.org>
Subject: Re: Test for CFS Bandwidth Control V6
Date: Tue, 7 Jun 2011 19:54:34 -0700 [thread overview]
Message-ID: <BANLkTikPrs7b-QVoZZwerbHnCHpStgKj9w@mail.gmail.com> (raw)
In-Reply-To: <4DDB0199.6030805@jp.fujitsu.com>
[ Sorry for the delayed response, I was out on vacation for the second
half of May until last week -- I've now caught up on email and am
preparing the next posting ]
On Mon, May 23, 2011 at 5:53 PM, Hidetoshi Seto
<seto.hidetoshi@jp.fujitsu.com> wrote:
> Hi Paul and Xiao,
>
> Please check/test a fix at the foot of this mail.
>
> (2011/05/20 11:12), Xiao Guangrong wrote:
>> Hi Paul,
>>
>> I'm so sorry for sending this mail in the new thread, since i didn't
>> receive your V6 patchset from LKML.
>>
>> It seams the patchset can not be applied, since it's conflict between
>> patch 3 and patch 5:
>>
>> ========Quote========
> (snip)
>> ========End quote========
>
> Maybe I've fixed it by hand, or git-am is so wonderful.
>
> I believe Paul will do it right for next time.
>
>>
>> I downloaded the patchset from Internet, i missed the newer version?
>>
>> I have done some test after fixed the conflict by handle, below test can cause
>> box crash:
>>
>> ========Quote cpu_hotlpug.sh ========
> (snip)
>> ======== End quote cpu_hotlpug.sh ========
>>
>> Sorry to disturb you if the bug is know.
>>
>> Thanks!
>
> Thank you for reporting it, Xiao!
>
> I confirmed that running your test cause hung-up on my box.
> And after some investigation, I found that this is an infinite loop
> in migrate_task() due to miscalculation of rq->nr_running; when a
> task is queued to throttled entity the nr_running is incremented at
> the queuing and also the unthrottling.
>
> I made a fix for this bug and it seems works well for me.
> Could you try this patch and give us your feedback, Xiao?
>
> Thanks,
> H.Seto
>
> ---
> kernel/sched_fair.c | 28 +++++++++++++---------------
> 1 files changed, 13 insertions(+), 15 deletions(-)
>
> diff --git a/kernel/sched_fair.c b/kernel/sched_fair.c
> index 3936393..544072f 100644
> --- a/kernel/sched_fair.c
> +++ b/kernel/sched_fair.c
> @@ -1537,7 +1537,7 @@ static void unthrottle_cfs_rq(struct cfs_rq *cfs_rq)
> walk_tg_tree_from(cfs_rq->tg, tg_unthrottle_down, tg_nop,
> (void *)&udd);
>
> - if (!cfs_rq->load.weight)
> + if (!cfs_rq->h_nr_running)
> return;
>
Why change here?
> task_delta = cfs_rq->h_nr_running;
> @@ -1843,10 +1843,9 @@ enqueue_task_fair(struct rq *rq, struct task_struct *p, int flags)
> cfs_rq->h_nr_running++;
>
> /* end evaluation on throttled cfs_rq */
> - if (cfs_rq_throttled(cfs_rq)) {
> - se = NULL;
Hmm.. yeah this is a casualty of moving the h_nr_running computations
in-line as a part of the previous refactoring within the last
releases. This optimization (setting se = NULL to skip the second
half) obviously won't work properly with detecting whether we made it
to the end of the tree.
> - break;
> - }
> + if (cfs_rq_throttled(cfs_rq))
> + goto done;
> +
> flags = ENQUEUE_WAKEUP;
> }
>
> @@ -1855,14 +1854,14 @@ enqueue_task_fair(struct rq *rq, struct task_struct *p, int flags)
> cfs_rq->h_nr_running++;
>
> if (cfs_rq_throttled(cfs_rq))
> - break;
> + goto done;
>
> update_cfs_load(cfs_rq, 0);
> update_cfs_shares(cfs_rq);
> }
>
> - if (!se)
> - inc_nr_running(rq);
> + inc_nr_running(rq);
> +done:
> hrtick_update(rq);
> }
>
> @@ -1885,10 +1884,9 @@ static void dequeue_task_fair(struct rq *rq, struct task_struct *p, int flags)
> cfs_rq->h_nr_running--;
>
> /* end evaluation on throttled cfs_rq */
> - if (cfs_rq_throttled(cfs_rq)) {
> - se = NULL;
> - break;
> - }
> + if (cfs_rq_throttled(cfs_rq))
> + goto done;
> +
> /* Don't dequeue parent if it has other entities besides us */
> if (cfs_rq->load.weight) {
> /* Avoid double update below. */
> @@ -1910,14 +1908,14 @@ static void dequeue_task_fair(struct rq *rq, struct task_struct *p, int flags)
> cfs_rq->h_nr_running--;
>
> if (cfs_rq_throttled(cfs_rq))
> - break;
> + goto done;
>
> update_cfs_load(cfs_rq, 0);
> update_cfs_shares(cfs_rq);
> }
>
> - if (!se)
> - dec_nr_running(rq);
> + dec_nr_running(rq);
> +done:
> hrtick_update(rq);
> }
>
> --
> 1.7.4.4
>
>
>
How about instead something like the following. We can actually take
advantage of the second loop always executing by deferring the
accounting update on a throttle entity. This keeps the control flow
within dequeue_task_fair linear.
What do you think of (untested):
--- a/kernel/sched_fair.c
+++ b/kernel/sched_fair.c
@@ -1744,13 +1744,12 @@ enqueue_task_fair(struct rq *rq, struct
task_struct *p, int flags)
break;
cfs_rq = cfs_rq_of(se);
enqueue_entity(cfs_rq, se, flags);
- cfs_rq->h_nr_running++;
- /* end evaluation on throttled cfs_rq */
- if (cfs_rq_throttled(cfs_rq)) {
- se = NULL;
+ /* note: ordering with throttle check to perform
h_nr_running accounting on throttled entity below */
+ if (cfs_rq_throttled(cfs_rq))
break;
- }
+
+ cfs_rq->h_nr_running++;
flags = ENQUEUE_WAKEUP;
}
@@ -1786,13 +1785,12 @@ static void dequeue_task_fair(struct rq *rq,
struct task_struct *p, int flags)
for_each_sched_entity(se) {
cfs_rq = cfs_rq_of(se);
dequeue_entity(cfs_rq, se, flags);
- cfs_rq->h_nr_running--;
- /* end evaluation on throttled cfs_rq */
- if (cfs_rq_throttled(cfs_rq)) {
- se = NULL;
+ /* note: ordering with throttle check to perform
h_nr_running accounting on throttled entity below */
+ if (cfs_rq_throttled(cfs_rq))
break;
- }
+
+ cfs_rq->h_nr_running--;
/* Don't dequeue parent if it has other entities besides
next prev parent reply other threads:[~2011-06-08 2:55 UTC|newest]
Thread overview: 63+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-03-23 3:03 [patch 00/15] CFS Bandwidth Control V5 Paul Turner
2011-03-23 3:03 ` [patch 01/15] sched: introduce primitives to account for CFS bandwidth tracking Paul Turner
2011-03-24 12:38 ` Kamalesh Babulal
2011-04-05 13:28 ` Peter Zijlstra
2011-03-23 3:03 ` [patch 02/15] sched: validate CFS quota hierarchies Paul Turner
2011-03-23 10:39 ` torbenh
2011-03-23 20:49 ` Paul Turner
2011-03-24 6:31 ` Bharata B Rao
2011-04-08 17:01 ` Peter Zijlstra
2011-03-29 6:57 ` Hidetoshi Seto
2011-04-04 23:10 ` Paul Turner
2011-04-05 13:28 ` Peter Zijlstra
2011-03-23 3:03 ` [patch 03/15] sched: accumulate per-cfs_rq cpu usage Paul Turner
2011-04-05 13:28 ` Peter Zijlstra
2011-04-06 20:44 ` Paul Turner
2011-04-05 13:28 ` Peter Zijlstra
2011-04-06 20:47 ` Paul Turner
2011-03-23 3:03 ` [patch 04/15] sched: throttle cfs_rq entities which exceed their local quota Paul Turner
2011-03-23 5:09 ` Mike Galbraith
2011-03-23 20:53 ` Paul Turner
2011-03-24 6:36 ` Bharata B Rao
2011-03-24 7:40 ` Paul Turner
2011-04-05 13:28 ` Peter Zijlstra
2011-04-05 23:15 ` Paul Turner
2011-03-23 3:03 ` [patch 05/15] sched: unthrottle cfs_rq(s) who ran out of quota at period refresh Paul Turner
2011-04-05 13:28 ` Peter Zijlstra
2011-04-05 13:33 ` Peter Zijlstra
2011-04-05 13:28 ` Peter Zijlstra
2011-04-05 13:28 ` Peter Zijlstra
2011-03-23 3:03 ` [patch 06/15] sched: allow for positional tg_tree walks Paul Turner
2011-03-23 3:03 ` [patch 07/15] sched: prevent interactions between throttled entities and load-balance Paul Turner
2011-04-05 13:28 ` Peter Zijlstra
2011-03-23 3:03 ` [patch 08/15] sched: migrate throttled tasks on HOTPLUG Paul Turner
2011-04-05 13:28 ` Peter Zijlstra
2011-04-06 2:31 ` Paul Turner
2011-03-23 3:03 ` [patch 09/15] sched: add exports tracking cfs bandwidth control statistics Paul Turner
2011-04-05 13:28 ` Peter Zijlstra
2011-03-23 3:03 ` [patch 10/15] sched: (fixlet) dont update shares twice on on_rq parent Paul Turner
2011-04-05 13:28 ` Peter Zijlstra
2011-03-23 3:03 ` [patch 11/15] sched: hierarchical task accounting for SCHED_OTHER Paul Turner
2011-04-05 13:28 ` Peter Zijlstra
2011-03-23 3:03 ` [patch 12/15] sched: maintain throttled rqs as a list Paul Turner
2011-04-22 2:50 ` Hidetoshi Seto
2011-04-24 21:23 ` Paul Turner
2011-03-23 3:03 ` [patch 13/15] sched: expire slack quota using generation counters Paul Turner
2011-04-05 13:28 ` Peter Zijlstra
2011-04-06 7:22 ` Paul Turner
2011-04-06 8:15 ` Peter Zijlstra
2011-04-06 11:26 ` Peter Zijlstra
2011-03-23 3:03 ` [patch 14/15] sched: return unused quota on voluntary sleep Paul Turner
2011-04-05 13:28 ` Peter Zijlstra
2011-04-06 2:25 ` Paul Turner
2011-03-23 3:03 ` [patch 15/15] sched: add documentation for bandwidth control Paul Turner
2011-03-24 6:38 ` Bharata B Rao
2011-03-24 16:12 ` [patch 00/15] CFS Bandwidth Control V5 Bharata B Rao
2011-03-31 7:57 ` Xiao Guangrong
2011-04-04 23:10 ` Paul Turner
2011-04-05 13:28 ` Peter Zijlstra
2011-05-20 2:12 ` Test for CFS Bandwidth Control V6 Xiao Guangrong
2011-05-24 0:53 ` Hidetoshi Seto
2011-05-24 7:56 ` Xiao Guangrong
2011-06-08 2:54 ` Paul Turner [this message]
2011-06-08 5:55 ` Hidetoshi Seto
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=BANLkTikPrs7b-QVoZZwerbHnCHpStgKj9w@mail.gmail.com \
--to=pjt@google.com \
--cc=a.p.zijlstra@chello.nl \
--cc=balbir@linux.vnet.ibm.com \
--cc=bharata@linux.vnet.ibm.com \
--cc=dhaval.giani@gmail.com \
--cc=kamalesh@linux.vnet.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=seto.hidetoshi@jp.fujitsu.com \
--cc=svaidy@linux.vnet.ibm.com \
--cc=vatsa@in.ibm.com \
--cc=xemul@openvz.org \
--cc=xiaoguangrong@cn.fujitsu.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 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).