public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Dave Hansen <dave@linux.vnet.ibm.com>
To: Salman Qazi <sqazi@google.com>
Cc: linux-kernel@vger.kernel.org, Ingo Molnar <mingo@elte.hu>,
	Thomas Gleixner <tglx@linutronix.de>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Andi Kleen <andi@firstfloor.org>,
	Dave Hansen <haveblue@us.ibm.com>,
	nickpiggin@yahoo.com.au,
	Linus Torvalds <torvalds@linux-foundation.org>
Subject: Re: Another Performance Regression in write() syscall
Date: Mon, 23 Feb 2009 22:25:45 -0800	[thread overview]
Message-ID: <1235456745.26788.237.camel@nimitz> (raw)
In-Reply-To: <20090224060558.GA14812@google.com>

On Mon, 2009-02-23 at 22:05 -0800, Salman Qazi wrote:
> Analysis of profile data has led us to believe that the commit
> 3d733633a633065729c9e4e254b2e5442c00ef7e has caused a performance
> regression.  This commit provides for tracking of writers so that read only
> bind mounts function correctly.
> 
> We can verify this regression by applying the following patch to partially
> disable the above-mentioned commit and then running the fstime component
> of Unixbench.  The settings used were 256 byte writes with MAX_BLOCK of 2000.

I'm a bit surprised that write() is what is regressing.  Unless I
screwed up, we do all the expensive accounting at open()/close() time.
Is this a test that gets run in parallel on multiple cpus?  

Could you take a look at Nick's patches to speed this stuff up?

	http://thread.gmane.org/gmane.linux.file-systems/28186

We may need to dust those off, although I'm still a bit worried about
the complexities of open-coding all the barriers.

Could we also see some kind of profile?  What kind of machine are you
seeing this on, btw?

-- Dave


  reply	other threads:[~2009-02-24  6:25 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-02-24  6:05 Another Performance Regression in write() syscall Salman Qazi
2009-02-24  6:25 ` Dave Hansen [this message]
2009-02-24  8:47   ` Nick Piggin
2009-02-24 16:58     ` Dave Hansen
2009-02-24 17:29       ` Linus Torvalds
2009-02-24 17:50         ` Ingo Molnar
2009-02-25  3:49       ` Nick Piggin
2009-02-25  1:05   ` Salman Qazi

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=1235456745.26788.237.camel@nimitz \
    --to=dave@linux.vnet.ibm.com \
    --cc=andi@firstfloor.org \
    --cc=haveblue@us.ibm.com \
    --cc=hpa@zytor.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=nickpiggin@yahoo.com.au \
    --cc=sqazi@google.com \
    --cc=tglx@linutronix.de \
    --cc=torvalds@linux-foundation.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