mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
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

  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