From: Frederic Weisbecker <fweisbec@gmail.com>
To: Vincent Guittot <vincent.guittot@linaro.org>
Cc: linux-kernel <linux-kernel@vger.kernel.org>,
"linaro-kernel@lists.linaro.org" <linaro-kernel@lists.linaro.org>,
Peter Zijlstra <peterz@infradead.org>,
Ingo Molnar <mingo@kernel.org>
Subject: Re: [PATCH] sched: fix clear NOHZ_BALANCE_KICK
Date: Tue, 4 Jun 2013 11:56:36 +0200 [thread overview]
Message-ID: <20130604095634.GA14012@somewhere> (raw)
In-Reply-To: <CAKfTPtCB_ftNWjgAM9s79dX_tuS4yevjdD0YxvKfKS4dxz=LLQ@mail.gmail.com>
On Tue, Jun 04, 2013 at 10:21:06AM +0200, Vincent Guittot wrote:
> On 4 June 2013 00:48, Frederic Weisbecker <fweisbec@gmail.com> wrote:
> > On Thu, May 30, 2013 at 05:23:05PM +0200, Vincent Guittot wrote:
> >> I have faced a sequence where the Idle Load Balance was sometime not
> >> triggered for a while on my platform.
> >>
> >> CPU 0 and CPU 1 are running tasks and CPU 2 is idle
> >>
> >> CPU 1 kicks the Idle Load Balance
> >> CPU 1 selects CPU 2 as the new Idle Load Balancer
> >> CPU 1 sets NOHZ_BALANCE_KICK for CPU 2
> >> CPU 1 sends a reschedule IPI to CPU 2
> >> While CPU 2 wakes up, CPU 0 or CPU 1 migrates a waking task A on CPU 2
> >> CPU 2 finally wakes up, runs task A and discards the Idle Load Balance
> >> Task A quickly goes back to sleep (before a tick occurs on CPU 2)
> >> CPU 2 goes back to idle with NOHZ_BALANCE_KICK set
> >>
> >> Whenever CPU 2 will be selected for the ILB, reschedule IPI will be not
> >> sent to CPU2, which is idle, because NOHZ_BALANCE_KICK is already set
> >> and no Idle Load Balance will be performed.
> >>
> >> We must wait for the sched softirq to be raised on CPU 2 thanks to
> >> another part of the kernel to clear NOHZ_BALANCE_KICKand come back to
> >> a normal situation.
> >>
> >> The proposed solution clears NOHZ_BALANCE_KICK in schedule_ipi if
> >> we can't raise the sched_softirq for the Idle Load Balance.
> >>
> >> Signed-off-by: Vincent Guittot <vincent.guittot@linaro.org>
> >> ---
> >> kernel/sched/core.c | 3 ++-
> >> 1 file changed, 2 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/kernel/sched/core.c b/kernel/sched/core.c
> >> index 58453b8..51fc715 100644
> >> --- a/kernel/sched/core.c
> >> +++ b/kernel/sched/core.c
> >> @@ -1420,7 +1420,8 @@ void scheduler_ipi(void)
> >> if (unlikely(got_nohz_idle_kick() && !need_resched())) {
> >> this_rq()->idle_balance = 1;
> >> raise_softirq_irqoff(SCHED_SOFTIRQ);
> >> - }
> >> + } else
> >> + clear_bit(NOHZ_BALANCE_KICK, nohz_flags(smp_processor_id()));
> >
> > But then do we reach this if the IPI happens while running the non-idle task in
> > CPU 2? The first got_nohz_idle_kick() test would drop us out early from scheduler_ipi()
> > due to the idle_cpu() test. So the flag doesn't get cleared in this case.
>
> The 1st point is that only idle cpu can be selected for idle load
> balance. But this doesn't prevent the cpu to wake up while it is
> kicked for idle load balance.
Yep.
> I had added the clear_bit for the 1st got_nohz_idle_kick in the draft
> version of this patch but the test of the emptiness of the wake_list,
> the call to smp_send_reschedule in the various way to wake up the idle
> cpu and the results of the tests have convinced me (may be wrongly)
> that it was not necessary.
Hmm, if the CPU is idle, get selected as an ilb, but then the CPU schedules
a non-idle task and receive the IPI in this non-idle context then finally
it goes back to idle for a long time. It can stay idle without ever been
notified with this NOHZ_BALANCE_KICK flag set.
But I can be missing something that clears the flag somewhere in that scenario.
In any case it's not obvious.
prev parent reply other threads:[~2013-06-04 9:56 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-05-30 15:23 [PATCH] sched: fix clear NOHZ_BALANCE_KICK Vincent Guittot
2013-06-03 22:48 ` Frederic Weisbecker
2013-06-04 8:21 ` Vincent Guittot
2013-06-04 9:36 ` Peter Zijlstra
2013-06-04 10:26 ` Frederic Weisbecker
2013-06-04 11:11 ` Vincent Guittot
2013-06-04 11:19 ` Frederic Weisbecker
2013-06-04 11:48 ` Vincent Guittot
2013-06-04 14:44 ` Frederic Weisbecker
2013-06-04 15:29 ` Vincent Guittot
2013-06-05 13:31 ` Frederic Weisbecker
2013-06-04 11:15 ` Peter Zijlstra
2013-06-04 11:53 ` Frederic Weisbecker
2013-06-04 9:56 ` Frederic Weisbecker [this message]
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=20130604095634.GA14012@somewhere \
--to=fweisbec@gmail.com \
--cc=linaro-kernel@lists.linaro.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@kernel.org \
--cc=peterz@infradead.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.