All of lore.kernel.org
 help / color / mirror / Atom feed
From: Eric Dumazet <eric.dumazet@gmail.com>
To: Andi Kleen <andi@firstfloor.org>
Cc: Thomas Gleixner <tglx@linutronix.de>,
	john stultz <johnstul@us.ibm.com>,
	lkml <linux-kernel@vger.kernel.org>,
	Paul Mackerras <paulus@samba.org>,
	"Paul E. McKenney" <paulmck@linux.vnet.ibm.com>,
	Anton Blanchard <anton@samba.org>, Ingo Molnar <mingo@elte.hu>
Subject: Re: [RFC] time: xtime_lock is held too long
Date: Fri, 06 May 2011 03:41:43 +0200	[thread overview]
Message-ID: <1304646103.3131.3.camel@edumazet-laptop> (raw)
In-Reply-To: <20110505210118.GI2925@one.firstfloor.org>

Le jeudi 05 mai 2011 à 23:01 +0200, Andi Kleen a écrit :
> > > Another idea would be to prime cache lines to be dirtied in cpu cache
> > > before taking locks, and better pack variables to reduce number of cache
> > > lines.
> > 
> > Most variables are packed already in struct timekeeper, which should
> > be pretty cache hot anyway, so I don't know whether we gain much.
> 
> There's actually some potential here. I got a moderate speedup in a
> database benchmark with this patch recently. The biggest win
> was in the timer interrupt.
> 
> All those variables are on separate cache lines.
> 
> (needs some cleanups, just for illustration)
> 
> -Andi
> 
> From: Andi Kleen <ak@linux.intel.com>
> Subject: [PATCH] do prefetches for timer state in timer interrupt
> 
> diff --git a/arch/x86/kernel/apic/apic.c b/arch/x86/kernel/apic/apic.c
> index 76b96d7..2704267 100644
> --- a/arch/x86/kernel/apic/apic.c
> +++ b/arch/x86/kernel/apic/apic.c
> @@ -856,6 +856,17 @@ void __irq_entry smp_apic_timer_interrupt(struct pt_regs *regs)
>  {
>  	struct pt_regs *old_regs = set_irq_regs(regs);
>  
> +	extern struct timespec xtime;
> +	extern struct timespec wall_to_monotonic;
> +
> +
> +	/* Prefetch here to make the ktime_get later faster.
> + 	 * XXX move them all on the same cache line.
> + 	 */
> +	prefetch(&xtime_lock);
> +	prefetch(&xtime);
> +	prefetch(&wall_to_monotonic);
> +
>  	/*
>  	 * NOTE! We'd better ACK the irq immediately,
>  	 * because timer handling can be slow.
> diff --git a/kernel/time/timekeeping.c b/kernel/time/timekeeping.c
> index d27c756..0002e9e 100644
> --- a/kernel/time/timekeeping.c
> +++ b/kernel/time/timekeeping.c
> @@ -157,8 +157,8 @@ __cacheline_aligned_in_smp DEFINE_SEQLOCK(xtime_lock);
>   * - wall_to_monotonic is no longer the boot time, getboottime must be
>   * used instead.
>   */
> -static struct timespec xtime __attribute__ ((aligned (16)));
> -static struct timespec wall_to_monotonic __attribute__ ((aligned (16)));
> +struct timespec xtime __attribute__ ((aligned (16)));
> +struct timespec wall_to_monotonic __attribute__ ((aligned (16)));
>  static struct timespec total_sleep_time;
>  
>  /*
> 


Did you tried prefetchw() by any chance ?




  reply	other threads:[~2011-05-06  1:41 UTC|newest]

Thread overview: 50+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-05-04  3:11 [PATCH] time: Add locking to xtime access in get_seconds() John Stultz
2011-05-04  3:52 ` Andi Kleen
2011-05-05  2:54   ` john stultz
2011-05-05  5:44     ` Eric Dumazet
2011-05-05  6:21       ` john stultz
2011-05-05  6:50         ` Eric Dumazet
2011-05-05  8:14         ` Paul E. McKenney
2011-05-05 18:51           ` john stultz
2011-05-05 14:04         ` [RFC] time: xtime_lock is held too long Eric Dumazet
2011-05-05 14:39           ` Thomas Gleixner
2011-05-05 15:08             ` Eric Dumazet
2011-05-05 15:59               ` Thomas Gleixner
2011-05-05 21:01                 ` Andi Kleen
2011-05-06  1:41                   ` Eric Dumazet [this message]
2011-05-06  6:55                     ` Andi Kleen
2011-05-06 10:18                   ` Thomas Gleixner
2011-05-06 10:22                     ` Ingo Molnar
2011-05-06 16:53                       ` Andi Kleen
2011-05-07  8:20                         ` Ingo Molnar
2011-05-06 16:59                     ` Andi Kleen
2011-05-06 17:09                       ` Eric Dumazet
2011-05-06 17:17                         ` Andi Kleen
2011-05-06 17:42                       ` Eric Dumazet
2011-05-06 17:50                         ` Andi Kleen
2011-05-06 19:26                           ` Eric Dumazet
2011-05-06 20:04                             ` Eric Dumazet
2011-05-06 20:24                               ` john stultz
2011-05-06 22:30                                 ` Eric Dumazet
2011-05-06 22:46                                   ` john stultz
2011-05-06 23:00                                     ` Eric Dumazet
2011-05-06 23:28                                       ` john stultz
2011-05-07  5:02                                         ` Eric Dumazet
2011-05-07  7:11                                           ` Henrik Rydberg
2011-05-09  8:40                                         ` Thomas Gleixner
2011-05-12  9:13                                         ` [PATCH] seqlock: don't smp_rmb in seqlock reader spin loop, [PATCH] seqlock: don't smp_rmb in seqlock reader spin loop Milton Miller
2011-05-12  9:13                                           ` Milton Miller
2011-05-12  9:35                                           ` Eric Dumazet
2011-05-12  9:35                                             ` Eric Dumazet
2011-05-12 14:08                                           ` Andi Kleen
2011-05-12 14:08                                             ` Andi Kleen
2011-05-06 20:18                         ` [RFC] time: xtime_lock is held too long john stultz
2011-05-05 17:57     ` [PATCH] time: Add locking to xtime access in get_seconds() Andi Kleen
2011-05-05 20:17       ` john stultz
2011-05-05 20:24         ` Eric Dumazet
2011-05-05 20:40           ` john stultz
2011-05-05 20:43             ` Eric Dumazet
2011-05-05 20:56         ` Andi Kleen
2011-05-04 16:51 ` Max Asbock
2011-05-04 21:05   ` Andi Kleen
2011-05-04 23:05   ` john stultz

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=1304646103.3131.3.camel@edumazet-laptop \
    --to=eric.dumazet@gmail.com \
    --cc=andi@firstfloor.org \
    --cc=anton@samba.org \
    --cc=johnstul@us.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=paulmck@linux.vnet.ibm.com \
    --cc=paulus@samba.org \
    --cc=tglx@linutronix.de \
    /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.