All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ingo Molnar <mingo@elte.hu>
To: Thomas Gleixner <tglx@linutronix.de>
Cc: Andi Kleen <andi@firstfloor.org>,
	Eric Dumazet <eric.dumazet@gmail.com>,
	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>
Subject: Re: [RFC] time: xtime_lock is held too long
Date: Fri, 6 May 2011 12:22:32 +0200	[thread overview]
Message-ID: <20110506102232.GA11036@elte.hu> (raw)
In-Reply-To: <alpine.LFD.2.02.1105061117220.3005@ionos>


* Thomas Gleixner <tglx@linutronix.de> wrote:

> On Thu, 5 May 2011, Andi Kleen wrote:
> 
> > > > 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
> 
> Numbers please.

I'd suggest to create and publish a seqlock usage worst-case testcase, 
something that runs N threads on an N CPU system.

Then precise measurements have to be done on the source of cache misses, the 
total cost of the timer interrupt, etc.

I.e. this should be analyzed and improved properly, not just sloppily slapping 
a few prefetches here and there, which wont really *solve* anything ...

Thanks,

	Ingo

  reply	other threads:[~2011-05-06 10:23 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
2011-05-06  6:55                     ` Andi Kleen
2011-05-06 10:18                   ` Thomas Gleixner
2011-05-06 10:22                     ` Ingo Molnar [this message]
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=20110506102232.GA11036@elte.hu \
    --to=mingo@elte.hu \
    --cc=andi@firstfloor.org \
    --cc=anton@samba.org \
    --cc=eric.dumazet@gmail.com \
    --cc=johnstul@us.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    --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.