public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Tuan Bui <tuan.d.bui@hp.com>
To: Arnaldo Carvalho de Melo <acme@kernel.org>
Cc: Ingo Molnar <mingo@kernel.org>,
	linux-kernel@vger.kernel.org, dbueso@suse.de,
	a.p.zijlstra@chello.nl, paulus@samba.org, artagnon@gmail.com,
	jolsa@redhat.com, dvhart@linux.intel.com,
	Aswin Chandramouleeswaran <aswin@hp.com>,
	Jason Low <jason.low2@hp.com>,
	akpm@linux-foundation.org
Subject: Re: [RFC PATCH] Perf Bench: Locking Microbenchmark
Date: Wed, 08 Oct 2014 15:11:11 -0700	[thread overview]
Message-ID: <1412806271.2908.3.camel@u64> (raw)
In-Reply-To: <20141001171226.GF2799@kernel.org>

On Wed, 2014-10-01 at 14:12 -0300, Arnaldo Carvalho de Melo wrote:
> Em Wed, Oct 01, 2014 at 07:28:32AM +0200, Ingo Molnar escreveu:
> > If you compare an strace of AIM7 steady state and 'perf bench 
> > lock' steady state, is it comparable, i.e. do the syscalls and 
> 
> Isn't "lock" too generic? Isn't this stressing some specific lock and if
> so shouldn't that be made abundantly clear in the 'perf bench' test name
> and in the docs?
> 

In this micro benchmark, I am trying to exhibit the same locking
contention shown in an AIM7 fserver workload.  Since the creat(2) system
call is file system dependent running this on different file system show
different lock being contended that is why i did not specify specific
lock name in the doc.  Do you have a suggestion here on how i should
name this benchmark?

> Or is this the case that it started by using 'creat' calls to stress
> some locking and will go on adding more syscalls to stress more kernel
> locks?
> 

When running all AIM7 workloads looking for locking contention to
reproduce, creat was the only one I found interesting and useful to
stress locking contention.





  parent reply	other threads:[~2014-10-08 22:11 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-09-30 23:49 [RFC PATCH] Perf Bench: Locking Microbenchmark Tuan Bui
2014-10-01  5:28 ` Ingo Molnar
2014-10-01 17:12   ` Arnaldo Carvalho de Melo
2014-10-03  4:57     ` Davidlohr Bueso
2014-10-08 22:14       ` Tuan Bui
2014-10-08 22:11     ` Tuan Bui [this message]
2014-10-03  4:52   ` Davidlohr Bueso
2014-10-08 22:13   ` Tuan Bui
2014-10-09  7:21     ` Ingo Molnar

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=1412806271.2908.3.camel@u64 \
    --to=tuan.d.bui@hp.com \
    --cc=a.p.zijlstra@chello.nl \
    --cc=acme@kernel.org \
    --cc=akpm@linux-foundation.org \
    --cc=artagnon@gmail.com \
    --cc=aswin@hp.com \
    --cc=dbueso@suse.de \
    --cc=dvhart@linux.intel.com \
    --cc=jason.low2@hp.com \
    --cc=jolsa@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@kernel.org \
    --cc=paulus@samba.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