All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tom Parkin <tparkin@katalix.com>
To: David Laight <David.Laight@ACULAB.COM>
Cc: netdev@vger.kernel.org, James Chapman <jchapman@katalix.com>
Subject: Re: [PATCH] l2tp: synchronise u64 stats writer callsites
Date: Thu, 21 Jun 2012 17:19:56 +0100	[thread overview]
Message-ID: <20120621161955.GA29812@jackdaw> (raw)
In-Reply-To: <AE90C24D6B3A694183C094C60CF0A2F6026B6F5D@saturn3.aculab.com>

[-- Attachment #1: Type: text/plain, Size: 1006 bytes --]

On Thu, Jun 21, 2012 at 04:18:12PM +0100, David Laight wrote:
> The purpose of the u64_stats_update_begin/end is to
> perform lockless writes of the stats.
> If you need to lock them (because multiple threads can
> be writing to stats covered by the same 'syncp' at the
> same time) then the reader might as well use the same lock.
> 
> Otherwise split the 'syncp' such that only one update
> can be happening (for each sync).

Thanks David.

I think the best approach is probably to attempt to partition the l2tp
statistics such that we can be sure of single-threaded writer access
for each dataset, which can then be covered by a 'syncp'.

If that turns out not to be possible, I suppose the fallback position
is to do away with the u64_stats_update* calls and just use a spinlock
instead.

I'll look at implementing the former and put a new patch together.

Tom
-- 
Tom Parkin
Katalix Systems Ltd
http://www.katalix.com
Catalysts for your Embedded Linux software development

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

      reply	other threads:[~2012-06-21 16:19 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-06-21 15:04 [PATCH] l2tp: synchronise u64 stats writer callsites Tom Parkin
2012-06-21 15:18 ` David Laight
2012-06-21 16:19   ` Tom Parkin [this message]

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=20120621161955.GA29812@jackdaw \
    --to=tparkin@katalix.com \
    --cc=David.Laight@ACULAB.COM \
    --cc=jchapman@katalix.com \
    --cc=netdev@vger.kernel.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 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.