From: Thomas Gleixner <tglx@linutronix.de>
To: Andi Kleen <andi@firstfloor.org>
Cc: LKML <linux-kernel@vger.kernel.org>,
Andi Kleen <ak@linux.intel.com>,
Eric Dumazet <eric.dumazet@gmail.com>,
Peter Zijlstra <peterz@infradead.org>
Subject: Re: [PATCH 3/3] tick-broadcast: push down tick_broadcast_lock
Date: Tue, 6 Sep 2011 18:19:00 +0200 (CEST) [thread overview]
Message-ID: <alpine.LFD.2.02.1109061652200.2723@ionos> (raw)
In-Reply-To: <1314652136-11350-3-git-send-email-andi@firstfloor.org>
On Mon, 29 Aug 2011, Andi Kleen wrote:
> From: Andi Kleen <ak@linux.intel.com>
>
> For the oneshot case, only take the tick_broadcast_lock when the
> global device is actually changing. For the case when the new
> event is only setting the wakeup to a later time than it already
> is we don't need the lock.
>
> This avoids lock contention for some special cases on systems
> that don't have an always running per cpu timer. It's not a full
> solution to the scalability problem there unfortunately, just
> the first step.
There is no full solution to that problem other than using sane
hardware.
> Signed-off-by: Andi Kleen <ak@linux.intel.com>
> ---
> kernel/time/tick-broadcast.c | 18 ++++++++++++++----
> 1 files changed, 14 insertions(+), 4 deletions(-)
>
> diff --git a/kernel/time/tick-broadcast.c b/kernel/time/tick-broadcast.c
> index 54a5977..7e748fb 100644
> --- a/kernel/time/tick-broadcast.c
> +++ b/kernel/time/tick-broadcast.c
> @@ -485,23 +485,33 @@ void tick_broadcast_oneshot_control(unsigned long reason)
>
> bc = tick_broadcast_device.evtdev;
>
> - raw_spin_lock_irqsave(&tick_broadcast_lock, flags);
> if (reason == CLOCK_EVT_NOTIFY_BROADCAST_ENTER) {
> if (!__get_cpu_var(state).need_oneshot) {
> __get_cpu_var(state).need_oneshot = 1;
> clockevents_set_mode(dev, CLOCK_EVT_MODE_SHUTDOWN);
> - if (dev->next_event.tv64 < bc->next_event.tv64)
> +
> + /* Only take the lock if the events gets set earlier */
> + if (dev->next_event.tv64 < bc->next_event.tv64) {
That's racy and broken.
CPU0 CPU1
tick_handle_oneshot_broadcast()
raw_spin_lock(&tick_broadcast_lock);
bc->next_event = KTIME_MAX;
for_each_online_cpu() {
next_event = ...;
}
.... if (dev->next_event < bc->next_event) {
raw_spin_lock(&tick_broadcast_lock);
tick_broadcast_set_event(next_event, 0);
bc->next_event = next_event;
raw_spin_unlock(&tick_broadcast_lock);
tick_broadcast_set_event(dev->next_event, 1);
So you unconditionally set the broadcast device to dev->next_event of
CPU1 even if the current pending event which was evaluated on CPU0 is
_BEFORE_ the CPU1 event. That can cause stalls and other hard to debug
horror. We've been there before.
Further the unprotected comparison on 32bit is completely bogus.
> + raw_spin_lock_irqsave(&tick_broadcast_lock, flags);
> tick_broadcast_set_event(dev->next_event, 1);
> + raw_spin_unlock_irqrestore(&tick_broadcast_lock,
> + flags);
> + }
> }
> } else {
> if (__get_cpu_var(state).need_oneshot) {
> __get_cpu_var(state).need_oneshot = 0;
> clockevents_set_mode(dev, CLOCK_EVT_MODE_ONESHOT);
> - if (dev->next_event.tv64 != KTIME_MAX)
> +
> + /* Only take the lock if the event changes */
> + if (dev->next_event.tv64 != KTIME_MAX) {
> + raw_spin_lock_irqsave(&tick_broadcast_lock, flags);
Why would you take the global lock to program the cpu local device?
Just because it happened to be under that lock before?
> tick_program_event(dev->next_event, 1);
> + raw_spin_unlock_irqrestore(&tick_broadcast_lock,
> + flags);
Thanks,
tglx
next prev parent reply other threads:[~2011-09-06 16:19 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-08-29 21:08 [PATCH 1/3] clockevents: Use an atomic RCU notifier for clockevents Andi Kleen
2011-08-29 21:08 ` [PATCH 2/3] broadcast-tick: Move oneshot broadcast mask to per cpu variables v2 Andi Kleen
2011-09-06 15:28 ` Thomas Gleixner
2011-08-29 21:08 ` [PATCH 3/3] tick-broadcast: push down tick_broadcast_lock Andi Kleen
2011-09-06 16:19 ` Thomas Gleixner [this message]
2011-09-06 17:49 ` Andi Kleen
2011-09-06 18:55 ` Thomas Gleixner
2011-09-06 19:23 ` [PATCH 1/3] clockevents: Use an atomic RCU notifier for clockevents Thomas Gleixner
2011-09-06 20:33 ` Andi Kleen
2011-09-06 21:45 ` Thomas Gleixner
2011-09-06 22:42 ` Andi Kleen
2011-09-06 23:19 ` Thomas Gleixner
-- strict thread matches above, loose matches on Subject: below --
2011-08-26 22:32 Andi Kleen
2011-08-26 22:32 ` [PATCH 3/3] tick-broadcast: push down tick_broadcast_lock Andi Kleen
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=alpine.LFD.2.02.1109061652200.2723@ionos \
--to=tglx@linutronix.de \
--cc=ak@linux.intel.com \
--cc=andi@firstfloor.org \
--cc=eric.dumazet@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=peterz@infradead.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Powered by JetHome