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 21:26:43 +0200	[thread overview]
Message-ID: <1304710003.2821.0.camel@edumazet-laptop> (raw)
In-Reply-To: <20110506175051.GL11636@one.firstfloor.org>

Le vendredi 06 mai 2011 à 19:50 +0200, Andi Kleen a écrit :
> On Fri, May 06, 2011 at 07:42:47PM +0200, Eric Dumazet wrote:
> > Le vendredi 06 mai 2011 à 18:59 +0200, Andi Kleen a écrit :
> > 
> > > If you have a better way to make it faster please share it.
> > 
> > Ideally we could use RCU :)
> 
> Hmm, I didn't think my case had a lot of loops in the seqlock -- just
> expensive cache misses -- but I should double check.
> 
> For the lots of loop case we probably need to understand first why you
> iterate that often.

Yep, I'll try to investigate on this

Thanks !



  reply	other threads:[~2011-05-06 19:26 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
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 [this message]
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=1304710003.2821.0.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.