linux-nfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jeff Layton <jlayton@redhat.com>
To: Jim Rees <rees@umich.edu>
Cc: "J. Bruce Fields" <bfields@fieldses.org>,
	viro@zeniv.linux.org.uk, matthew@wil.cx, dhowells@redhat.com,
	sage@inktank.com, smfrench@gmail.com, swhiteho@redhat.com,
	Trond.Myklebust@netapp.com, akpm@linux-foundation.org,
	linux-kernel@vger.kernel.org, linux-afs@lists.infradead.org,
	ceph-devel@vger.kernel.org, linux-cifs@vger.kernel.org,
	samba-technical@lists.samba.org, cluster-devel@redhat.com,
	linux-nfs@vger.kernel.org, linux-fsdevel@vger.kernel.org,
	piastryyy@gmail.com
Subject: Re: [PATCH v1 00/11] locks: scalability improvements for file locking
Date: Tue, 4 Jun 2013 08:15:17 -0400	[thread overview]
Message-ID: <20130604081517.0ad9f983@corrin.poochiereds.net> (raw)
In-Reply-To: <20130604115644.GA4180@umich.edu>

On Tue, 4 Jun 2013 07:56:44 -0400
Jim Rees <rees@umich.edu> wrote:

> Jeff Layton wrote:
> 
>   > Might be nice to look at some profiles to confirm all of that.  I'd also
>   > be curious how much variation there was in the results above, as they're
>   > pretty close.
>   > 
>   
>   The above is just a random representative sample. The results are
>   pretty close when running this test, but I can average up several runs
>   and present the numbers. I plan to get a bare-metal test box on which
>   to run some more detailed testing and maybe some profiling this week.
> 
> Just contributing more runs into the mean doesn't tell us anything about the
> variance. With numbers that close you need the variance to tell whether it's
> a significant change.

Thanks. I'll see if I can get some standard deviation numbers here, and
I'll do it on some bare metal to ensure that virtualization doesn't
skew any results.

FWIW, they were all consistently very close to one another when I ran
these tests, and the times were all consistently shorter than the
unpatched kernel.

That said, this test is pretty rough. Doing this with "time" measures
other things that aren't related to locking. So I'll also see if I
can come up with a way to measure the actual locking performance more
accurately too.

-- 
Jeff Layton <jlayton@redhat.com>

      reply	other threads:[~2013-06-04 12:15 UTC|newest]

Thread overview: 39+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-06-01  3:07 [PATCH v1 00/11] locks: scalability improvements for file locking Jeff Layton
2013-06-01  3:07 ` [PATCH v1 01/11] cifs: use posix_unblock_lock instead of locks_delete_block Jeff Layton
2013-06-03 21:53   ` J. Bruce Fields
2013-06-01  3:07 ` [PATCH v1 02/11] locks: make generic_add_lease and generic_delete_lease static Jeff Layton
2013-06-03 21:53   ` J. Bruce Fields
2013-06-01  3:07 ` [PATCH v1 03/11] locks: comment cleanups and clarifications Jeff Layton
2013-06-03 22:00   ` J. Bruce Fields
2013-06-04 11:09     ` Jeff Layton
2013-06-01  3:07 ` [PATCH v1 04/11] locks: make "added" in __posix_lock_file a bool Jeff Layton
2013-06-04 20:17   ` J. Bruce Fields
2013-06-01  3:07 ` [PATCH v1 05/11] locks: encapsulate the fl_link list handling Jeff Layton
2013-06-04 20:17   ` J. Bruce Fields
2013-06-01  3:07 ` [PATCH v1 06/11] locks: convert to i_lock to protect i_flock list Jeff Layton
2013-06-04 21:22   ` J. Bruce Fields
2013-06-05  0:46     ` Jeff Layton
2013-06-01  3:07 ` [PATCH v1 07/11] locks: only pull entries off of blocked_list when they are really unblocked Jeff Layton
2013-06-04 21:58   ` J. Bruce Fields
2013-06-05 11:38     ` Jeff Layton
2013-06-05 12:24       ` J. Bruce Fields
2013-06-05 12:38         ` Jeff Layton
2013-06-05 12:59           ` J. Bruce Fields
2013-06-01  3:07 ` [PATCH v1 08/11] locks: convert fl_link to a hlist_node Jeff Layton
2013-06-04 21:59   ` J. Bruce Fields
2013-06-05 11:43     ` Jeff Layton
2013-06-05 12:46       ` J. Bruce Fields
2013-06-01  3:07 ` [PATCH v1 09/11] locks: turn the blocked_list into a hashtable Jeff Layton
2013-06-01  3:07 ` [PATCH v1 10/11] locks: add a new "lm_owner_key" lock operation Jeff Layton
2013-06-01  3:07 ` [PATCH v1 11/11] locks: give the blocked_hash its own spinlock Jeff Layton
2013-06-04 14:19   ` Stefan (metze) Metzmacher
2013-06-04 14:39     ` Jeff Layton
2013-06-04 14:46     ` Christoph Hellwig
2013-06-04 14:53       ` J. Bruce Fields
2013-06-04 15:15         ` Jeff Layton
2013-06-04 14:56       ` Jeff Layton
2013-06-03 19:04 ` [PATCH v1 00/11] locks: scalability improvements for file locking Davidlohr Bueso
2013-06-03 21:31 ` J. Bruce Fields
2013-06-04 10:54   ` Jeff Layton
2013-06-04 11:56     ` Jim Rees
2013-06-04 12:15       ` Jeff Layton [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=20130604081517.0ad9f983@corrin.poochiereds.net \
    --to=jlayton@redhat.com \
    --cc=Trond.Myklebust@netapp.com \
    --cc=akpm@linux-foundation.org \
    --cc=bfields@fieldses.org \
    --cc=ceph-devel@vger.kernel.org \
    --cc=cluster-devel@redhat.com \
    --cc=dhowells@redhat.com \
    --cc=linux-afs@lists.infradead.org \
    --cc=linux-cifs@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-nfs@vger.kernel.org \
    --cc=matthew@wil.cx \
    --cc=piastryyy@gmail.com \
    --cc=rees@umich.edu \
    --cc=sage@inktank.com \
    --cc=samba-technical@lists.samba.org \
    --cc=smfrench@gmail.com \
    --cc=swhiteho@redhat.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).