All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Teigland <teigland@redhat.com>
To: cluster-devel.redhat.com
Subject: [Cluster-devel] GFS2: glock statistics gathering (RFC)
Date: Fri, 4 Nov 2011 12:31:52 -0400	[thread overview]
Message-ID: <20111104163152.GA15232@redhat.com> (raw)
In-Reply-To: <1320419989.2732.60.camel@menhir>

On Fri, Nov 04, 2011 at 03:19:49PM +0000, Steven Whitehouse wrote:
> The three pairs of mean/variance measure the following
> things:
> 
>  1. DLM lock time (non-blocking requests)

You don't need to track and save this value, because all results will be
one of three values which can gather once:

short: the dir node and master node are local: 0 network round trip
medium: one is local, one is remote: 1 network round trip
long: both are remote: 2 network round trips

Once you've measured values for short/med/long, then you're done.
The distribution will depend on the usage pattern.

>  2. DLM lock time (blocking requests)

I think what you want to quantify is how much contention a given lock is
under.  A time measurement is probably not a great way to get that since
it's a combination of: the value above, how long gfs2 takes to release the
lock (itself a combination of things, including the the tunable itself),
and how many nodes are competing for the lock (depends on workload).

>  3. Inter-request time (again to the DLM)

Time between gfs2 requesting the same lock?  That sounds like it might
work ok for measuring contention.

> 1. To be able to better set the glock "min hold time"

Less for a lock with high contention?

> 2. To spot performance issues more easily

Apart from contention, I'm not sure there are many perf issues that dlm
measurements would help with.

> 3. To improve the algorithm for selecting resource groups for
> allocation (to base it on lock wait time, rather than blindly
> using a "try lock")

Don't you grab an rg lock and keep it cached?  How would lock times help?

Also, ocfs2 keeps quite a lot of locking stats you might look at.

Dave



  reply	other threads:[~2011-11-04 16:31 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-11-04 15:19 [Cluster-devel] GFS2: glock statistics gathering (RFC) Steven Whitehouse
2011-11-04 16:31 ` David Teigland [this message]
2011-11-04 16:57   ` Steven Whitehouse
2011-11-04 17:21     ` David Teigland
2011-11-07 12:06       ` Steven Whitehouse

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=20111104163152.GA15232@redhat.com \
    --to=teigland@redhat.com \
    /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.