linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Chris Mason <chris.mason@oracle.com>
To: Tejun Heo <tj@kernel.org>
Cc: linux-btrfs <linux-btrfs@vger.kernel.org>
Subject: Re: [PATCH RFC] btrfs: Simplify locking
Date: Mon, 21 Mar 2011 13:24:37 -0400	[thread overview]
Message-ID: <1300728113-sup-8564@think> (raw)
In-Reply-To: <20110321165955.GG12003@htj.dyndns.org>

Excerpts from Tejun Heo's message of 2011-03-21 12:59:55 -0400:
> Hello,
> 
> Here are the results with voluntary preemption.  I've moved to a
> beefier machine for testing.  It's dual Opteron 2347, so dual socket,
> eight core.  The memory is limited to 1GiB to force IOs and the disk
> is the same OCZ Vertex 60gig SSD.  /proc/stat is captured before and
> after "dbench 50".
> 
> I ran the following four setups.
> 
> DFL    The current custom locking implementation.
> SIMPLE    Simple mutex conversion.  The first patch in this thread.
> SPIN    SIMPLE + mutex_tryspin().  The second patch in this thread.
> SPIN2    SPIN + mutex_tryspin() in btrfs_tree_lock().  Patch below.
> 
> SPIN2 should alleviate the voluntary preemption by might_sleep() in
> mutex_lock().
> 
>        USER   SYSTEM   SIRQ    CXTSW  THROUGHPUT
> DFL    49427  458210   1433  7683488     642.947
> SIMPLE 52836  471398   1427  3055384     705.369
> SPIN   52267  473115   1467  3005603     705.369
> SPIN2  52063  470453   1446  3092091     701.826
> 
> I'm running DFL again just in case but SIMPLE or SPIN seems to be a
> much better choice.

Very interesting.  Ok, I'll definitely rerun my benchmarks as well.  I
used dbench extensively during the initial tuning, but you're forcing
the memory low in order to force IO.

This case doesn't really hammer on the locks, it hammers on the
transition from spinning to blocking.  We want also want to compare
dbench entirely in ram, which will hammer on the spinning portion.

-chris

> 
> Thanks.
> 
> NOT-Signed-off-by: Tejun Heo <tj@kernel.org>
> ---
>  fs/btrfs/locking.h |    2 ++
>  1 file changed, 2 insertions(+)
> 
> Index: work/fs/btrfs/locking.h
> ===================================================================
> --- work.orig/fs/btrfs/locking.h
> +++ work/fs/btrfs/locking.h
> @@ -28,6 +28,8 @@ static inline bool btrfs_try_spin_lock(s
>  
>  static inline void btrfs_tree_lock(struct extent_buffer *eb)
>  {
> +    if (mutex_tryspin(&eb->lock))
> +        return;
>      mutex_lock(&eb->lock);
>  }
>  

  parent reply	other threads:[~2011-03-21 17:24 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-03-20 17:44 [PATCH RFC] btrfs: Simplify locking Tejun Heo
2011-03-20 19:56 ` Tejun Heo
2011-03-20 20:17   ` Tejun Heo
2011-03-21  0:10 ` Chris Mason
2011-03-21  8:29   ` Tejun Heo
2011-03-21 16:59     ` Tejun Heo
2011-03-21 17:11       ` Tejun Heo
2011-03-21 17:24       ` Chris Mason [this message]
2011-03-21 18:11         ` Tejun Heo
2011-03-22 23:13           ` Chris Mason
2011-03-23 10:46             ` Tejun Heo
2011-03-23 11:44               ` Chris Mason

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=1300728113-sup-8564@think \
    --to=chris.mason@oracle.com \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=tj@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 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).