Re: Another Performance Regression in write() syscall

[Nick Piggin]

On Tuesday 24 February 2009 17:25:45 Dave Hansen wrote:
> 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?

Don't forget touch_atime...

Still, open/close isn't unimportant either.


> 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.

I really need to do something about trying to push them upstream again
actually because we've got them in SLES11 tree.

It would be interesting to know how much the unixbench numbers improve
with the patches.

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


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/