From: Michael Monnerie <michael.monnerie@is.it-management.at>
To: xfs@oss.sgi.com
Subject: Re: [PATCH] bump up nr_to_write in xfs_vm_writepage
Date: Sat, 4 Jul 2009 01:51:19 +0200 [thread overview]
Message-ID: <200907040151.21013@zmi.at> (raw)
In-Reply-To: <4A4D26C5.9070606@redhat.com>
On Donnerstag 02 Juli 2009 Eric Sandeen wrote:
> With the following change things get moving again for xfs:
Amazeing, more than double speed with a one-liner. Do you have more such
lines? ;-)
> + /*
> + * VM calculation for nr_to_write seems off. Bump it way
> + * up, this gets simple streaming writes zippy again.
> + */
> + wbc->nr_to_write *= 4;
Could this be helpful here also: I've just transfered a copy of a
directory from our server to a Linux desktop. Nothing else running, just
an rsync from server to client, where the client has a Seagate 1TB ES.2
SATA disk, whhic can do about 80MB/s on large writes. But it did this,
measured on large files (>20MB each, no small files):
Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-
sz avgqu-sz await svctm %util
sdb 0,00 584,00 0,00 368,00 0,00 7448,00
40,48 148,64 401,40 2,72 100,00
All the time around 300+ IOps, which is OK, but only 7-10MB/s? That
can't be true. Then I killed the rsync process on the server, and the
writes on the client jumped up:
sdb 0,00 4543,40 0,00 333,40 0,00 44965,60
269,74 144,66 384,98 3,00 100,00
45MB/s is OK. I investigated a bit further: Seems the /proc/sys/vm
values are strange, clients kernel is # uname -a
Linux saturn 2.6.30-ZMI #1 SMP PREEMPT Wed Jun 10 20:07:31 CEST 2009
x86_64 x86_64 x86_64 GNU/Linux
This makes rsync slow:
cat /proc/sys/vm/dirty_*
0
5
0
8000
50
100
This fast:
cat /proc/sys/vm/dirty_*
cat dirty_*
16123456
0
524123456
8000
0
100
Seems more like a kernel related stuff, but do others see the same
thing?
So, I'm really out for a 1 week vacation now, have fun!
mfg zmi
--
// Michael Monnerie, Ing.BSc ----- http://it-management.at
// Tel: 0660 / 415 65 31 .network.your.ideas.
// PGP Key: "curl -s http://zmi.at/zmi.asc | gpg --import"
// Fingerprint: AC19 F9D5 36ED CD8A EF38 500E CE14 91F7 1C12 09B4
// Keyserver: wwwkeys.eu.pgp.net Key-ID: 1C1209B4
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
next prev parent reply other threads:[~2009-07-03 23:50 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-07-02 21:29 [PATCH] bump up nr_to_write in xfs_vm_writepage Eric Sandeen
2009-07-03 23:51 ` Michael Monnerie [this message]
2009-07-07 9:07 ` Olaf Weber
2009-07-07 10:19 ` Christoph Hellwig
2009-07-07 10:33 ` KOSAKI Motohiro
2009-07-07 10:44 ` Christoph Hellwig
2009-07-09 2:04 ` KOSAKI Motohiro
2009-07-09 13:01 ` Chris Mason
2009-07-10 7:12 ` KOSAKI Motohiro
2009-07-24 5:20 ` Felix Blyakher
2009-07-24 5:33 ` KOSAKI Motohiro
2009-07-24 12:05 ` Chris Mason
2009-07-07 11:37 ` Olaf Weber
2009-07-07 14:46 ` Christoph Hellwig
2009-07-07 15:17 ` Chris Mason
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=200907040151.21013@zmi.at \
--to=michael.monnerie@is.it-management.at \
--cc=xfs@oss.sgi.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox