All of lore.kernel.org
 help / color / mirror / Atom feed
From: Nick Piggin <npiggin@gmail.com>
To: Rusty Russell <rusty@rustcorp.com.au>
Cc: Nick Piggin <npiggin@kernel.dk>, Andi Kleen <ak@linux.intel.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	linux-kernel <linux-kernel@vger.kernel.org>,
	Alexander Viro <viro@zeniv.linux.org.uk>,
	"Srivatsa S. Bhat" <srivatsa.bhat@linux.vnet.ibm.com>,
	linux-fsdevel@vger.kernel.org
Subject: Re: [PATCH 3/3] brlocks/lglocks: turn into functions
Date: Wed, 9 May 2012 17:35:53 +1000	[thread overview]
Message-ID: <CAPa8GCCSBxZZVS+ROshEW9qXwXLpwkoeiFiL0xnSGW6rsDQyrA@mail.gmail.com> (raw)
In-Reply-To: <87sjfcfynb.fsf@rustcorp.com.au>

On 7 May 2012 13:39, Rusty Russell <rusty@rustcorp.com.au> wrote:
> On Fri, 20 Apr 2012 21:21:49 +1000, Nick Piggin <npiggin@kernel.dk> wrote:
>> This still not merged?
>
> No, I've been away.  I've put it in -next for tomorrow, though I'm not
> sure what the best way to get it to Linus next merge window.
>
>> There is a reason, which is performance. Extra function call, but also
>> IIRC the percpu accessor was not so fast doing it this way. Maybe
>> that's improved...
>>
>> So what's the performance difference?
>
> What benchmarks you usually run?  Feel free to try it out and report
> back; I only have small hardware here.

Nothing big. The actual scalability should be unchanged, because you're
not going to be dirtying any shared cachelines. It's the use of dynamic
percpu allocator and out of line calls etc which will slow down straight
line performance.

How many microseconds does it take to stat("./dir1/dir2/myfile"), for
example?

`git diff` of a large tree, for something more realistic but still going to
exercise that path.

WARNING: multiple messages have this Message-ID (diff)
From: Nick Piggin <npiggin@gmail.com>
To: Rusty Russell <rusty@rustcorp.com.au>
Cc: Nick Piggin <npiggin@kernel.dk>, Andi Kleen <ak@linux.intel.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	linux-kernel <linux-kernel@vger.kernel.org>,
	Alexander Viro <viro@zeniv.linux.org.uk>,
	"Srivatsa S. Bhat" <srivatsa.bhat@linux.vnet.ibm.com>,
	linux-fsdevel@vger.kernel.org
Subject: Re: [PATCH 3/3] brlocks/lglocks: turn into functions
Date: Wed, 9 May 2012 17:35:53 +1000	[thread overview]
Message-ID: <CAPa8GCCSBxZZVS+ROshEW9qXwXLpwkoeiFiL0xnSGW6rsDQyrA@mail.gmail.com> (raw)
In-Reply-To: <87sjfcfynb.fsf@rustcorp.com.au>

On 7 May 2012 13:39, Rusty Russell <rusty@rustcorp.com.au> wrote:
> On Fri, 20 Apr 2012 21:21:49 +1000, Nick Piggin <npiggin@kernel.dk> wrote:
>> This still not merged?
>
> No, I've been away.  I've put it in -next for tomorrow, though I'm not
> sure what the best way to get it to Linus next merge window.
>
>> There is a reason, which is performance. Extra function call, but also
>> IIRC the percpu accessor was not so fast doing it this way. Maybe
>> that's improved...
>>
>> So what's the performance difference?
>
> What benchmarks you usually run?  Feel free to try it out and report
> back; I only have small hardware here.

Nothing big. The actual scalability should be unchanged, because you're
not going to be dirtying any shared cachelines. It's the use of dynamic
percpu allocator and out of line calls etc which will slow down straight
line performance.

How many microseconds does it take to stat("./dir1/dir2/myfile"), for
example?

`git diff` of a large tree, for something more realistic but still going to
exercise that path.
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

  parent reply	other threads:[~2012-05-09  7:35 UTC|newest]

Thread overview: 45+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-02-27 23:22 [PATCH] cpumask: fix lg_lock/br_lock Rusty Russell
2012-02-27 23:53 ` Andrew Morton
2012-02-27 23:53   ` Andrew Morton
2012-02-28  8:43   ` Ingo Molnar
2012-02-28 11:25     ` Andi Kleen
2012-02-28 12:51       ` Ingo Molnar
2012-02-28 21:27     ` Andrew Morton
2012-02-29  5:44       ` Srivatsa S. Bhat
2012-02-29  9:17         ` Ingo Molnar
2012-02-29 11:12           ` Srivatsa S. Bhat
2012-03-01  7:38             ` Ingo Molnar
2012-03-01  9:15               ` Srivatsa S. Bhat
2012-03-01  9:45                 ` Ingo Molnar
2012-03-01  9:56                   ` Srivatsa S. Bhat
2012-03-01  8:12             ` Srivatsa S. Bhat
2012-03-01  8:24               ` Srivatsa S. Bhat
2012-03-01  8:12               ` Srivatsa S. Bhat
2012-03-01  8:15               ` [PATCH 1/3] CPU hotplug: Fix issues with callback registration Srivatsa S. Bhat
2012-03-01  8:27                 ` Srivatsa S. Bhat
2012-03-01  8:15                 ` Srivatsa S. Bhat
2012-03-01  8:16               ` [PATCH 2/3] CPU hotplug, arch/powerpc: Fix CPU hotplug " Srivatsa S. Bhat
2012-03-01  8:28                 ` Srivatsa S. Bhat
2012-03-01  8:16                 ` Srivatsa S. Bhat
2012-03-01  8:18               ` [PATCH 3/3] CPU hotplug, arch/sparc: " Srivatsa S. Bhat
2012-03-01  8:30                 ` Srivatsa S. Bhat
2012-03-01  8:18                 ` Srivatsa S. Bhat
2012-02-29  8:29       ` [PATCH] cpumask: fix lg_lock/br_lock Ingo Molnar
2012-02-29  8:58         ` Peter Zijlstra
2012-02-29  9:32           ` Ingo Molnar
2012-02-28 11:24   ` Andi Kleen
2012-03-05  7:02     ` Rusty Russell
2012-03-05  7:03     ` [PATCH 1/3] lglock: remove online variants of lock Rusty Russell
2012-04-20 11:12       ` Nick Piggin
2012-03-05  7:04     ` [PATCH 2/3] brlocks/lglocks: API cleanups Rusty Russell
2012-03-05  7:05     ` [PATCH 3/3] brlocks/lglocks: turn into functions Rusty Russell
2012-04-20 11:21       ` Nick Piggin
2012-05-07  3:39         ` Rusty Russell
2012-05-07  5:46           ` Al Viro
2012-05-08  3:59             ` [PATCH 1/3] lglock: remove online variants of lock Rusty Russell
2012-05-08  4:50               ` Al Viro
2012-05-08  6:12                 ` Rusty Russell
2012-05-08  4:02             ` [PATCH 2/3] brlocks/lglocks: API cleanups Rusty Russell
2012-05-08  4:02             ` [PATCH 3/3] brlocks/lglocks: turn into functions Rusty Russell
2012-05-09  7:35           ` Nick Piggin [this message]
2012-05-09  7:35             ` Nick Piggin

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=CAPa8GCCSBxZZVS+ROshEW9qXwXLpwkoeiFiL0xnSGW6rsDQyrA@mail.gmail.com \
    --to=npiggin@gmail.com \
    --cc=ak@linux.intel.com \
    --cc=akpm@linux-foundation.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=npiggin@kernel.dk \
    --cc=rusty@rustcorp.com.au \
    --cc=srivatsa.bhat@linux.vnet.ibm.com \
    --cc=viro@zeniv.linux.org.uk \
    /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.