From: Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>
To: Venki Pallipadi <venki@google.com>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>,
Paul Turner <pjt@google.com>, Ingo Molnar <mingo@elte.hu>,
Vaidyanathan Srinivasan <svaidy@linux.vnet.ibm.com>,
Kamalesh Babulal <kamalesh@linux.vnet.ibm.com>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH v1] sched: fix nohz idle load balancer issues
Date: Wed, 28 Sep 2011 10:04:27 +0530 [thread overview]
Message-ID: <20110928043427.GI4357@linux.vnet.ibm.com> (raw)
In-Reply-To: <CABeCy1YXKR89_uQm_XAyNJHPHkL+6JKxa-C+8Z_9ox7b_k2scQ@mail.gmail.com>
* Venki Pallipadi <venki@google.com> [2011-09-27 12:53:21]:
> Some comments:
>
> Another potential change here is to
> - either reverse the order of rebalance_domains() and
> nohz_idle_balance() in run_rebalance_domains()
I thought of that, but then realized that it won't influence our
"idle_at_tick" check in nohz_idle_balance(). Did you have any other benefit in
mind behind that change?
> - or to kick another idle CPU in case of need_resched() in nohz_idle_balance.
> This should help with idle balance of tickless CPUs when ilb CPU gets
> a new task through load balance and hence aborts ilb.
Yes good point. I will add that in next version.
> > - The patch introduces a 'nohz.next_balance_lock' spinlock which is used
> > to update nohz.next_balance, so that it stays as min(rq->next_balance).
> > This fixes issue #2. I don't like a global spinlock so much, but don't
> > see easy way out. Besides, this lock is taken in context of idle cpu.
> >
>
> The problem I see with this is that there is no way to reset
> next_balance when a previously idle CPU goes busy. This probably will
> result in frequent ilb than needed and potential power and
> performance(due to SMT or freq timer interrupts) impact.
That already seems to be an issue with existing code. One possibility is
to rescan idle cpus looking for the next min rq->next_balance (unless we
want to go for more sophisticated like a sorted list of rq->next_balance
in a rb-tree).
> > - It allows any busy cpu to kick ilb_cpu if it has greater than 2
> > runnable tasks. This addresses issue #3
>
>
> This again may have power impact with frequent kicking.
I don't know how much additional kicks it would add - I mean the system
is busy and ilb_cpu deserves a kick. With this, we are forcing it to
happen sooner rather than wait for first/second_pick_cpu to do
"justice"?
> Especially with higher number of logical CPUs. Likely cleaner way is to clear
> first_pick, second_pick on idle instead of clearing on tickless.
I think I tried that (cleared first/second_pick_cpu in
nohz_kick_needed() upon idle) but didn't get the best results. Let me
try that again and post idle time numbers.
> Would be interesting to see some tests power impact (or number of
> interrupts, resched IPIs etc) of this change. Both with netbook kind
> of systems and on servers with partially idle configuration.
Ok - will get some numbers in that regard as well.
- vatsa
next prev parent reply other threads:[~2011-09-28 4:34 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-09-26 11:50 [PATCH v1] sched: fix nohz idle load balancer issues Srivatsa Vaddagiri
2011-09-26 12:01 ` Srivatsa Vaddagiri
2011-09-27 6:32 ` Ingo Molnar
2011-09-27 10:31 ` Srivatsa Vaddagiri
2011-09-27 13:39 ` Ingo Molnar
2011-09-27 19:53 ` Venki Pallipadi
2011-09-27 23:49 ` Suresh Siddha
2011-09-28 4:15 ` Srivatsa Vaddagiri
2011-09-29 0:47 ` Suresh Siddha
2011-09-29 2:13 ` Srivatsa Vaddagiri
2011-09-29 8:15 ` Peter Zijlstra
2011-09-29 17:13 ` Suresh Siddha
2011-09-28 4:34 ` Srivatsa Vaddagiri [this message]
2011-09-28 4:39 ` Srivatsa Vaddagiri
2011-09-28 5:06 ` Srivatsa Vaddagiri
2011-09-28 14:17 ` Srivatsa Vaddagiri
2011-09-28 14:27 ` Srivatsa Vaddagiri
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=20110928043427.GI4357@linux.vnet.ibm.com \
--to=vatsa@linux.vnet.ibm.com \
--cc=a.p.zijlstra@chello.nl \
--cc=kamalesh@linux.vnet.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=pjt@google.com \
--cc=svaidy@linux.vnet.ibm.com \
--cc=venki@google.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.