Re: Another Performance Regression in write() syscall

On Mon, Feb 23, 2009 at 10:25 PM, Dave Hansen <dave@xxxxxxxxxxxxxxxxxx> 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?

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

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


The pair of patches seems to fix our problem. The benchmark results
for 2.6.29-rc6 + the above patches:

308200, 335850, 335900, 335150, 334700

Thanks for your help.

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?

It's an Opteron with with 4 cores. Unfortunately, I don't have a
profile for the upstream kernel.


-- Dave


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

Relevant Pages