From: Michael Monnerie <michael.monnerie@is.it-management.at>
To: xfs@oss.sgi.com
Subject: Re: [PATCH] fix readahead calculations in xfs_dir2_leaf_getdents()
Date: Wed, 23 Sep 2009 22:29:03 +0200 [thread overview]
Message-ID: <200909232229.03395@zmi.at> (raw)
In-Reply-To: <4ABA6C2E.2080104@sandeen.net>
On Mittwoch 23 September 2009 Eric Sandeen wrote:
> so that's slowed down a bit. Weird that more calls, originally, made
> it faster overall...?
You wrote in the patch description that bufsize went very large when it
got below zero. Could it mean that a that times a big readahead appeared
and that's why the speed improved?
Why have there been more calls before that patch?
> But one thing I noticed is that we choose readahead based on a guess
> at the readdir buffer size, and at least for glibc's readdir it has
> this:
>
> const size_t default_allocation =
> (4 * BUFSIZ < sizeof (struct dirent64) ?
> sizeof (struct dirent64) : 4 * BUFSIZ);
>
> where BUFSIZ is a magical 8192.
>
> But we do at max PAGE_SIZE which gives us almost no readahead ...
>
> So bumping our "bufsize" up to 32k, things speed up nicely. Wonder
> if the stock broken bufsize method led to more inadvertent
> readahead....
Is it possible to increase it more, to see if things still improve?
Maybe that made the difference in the old version?
In general, I'd opt for at least 64KB buffers, that's the smallest I/O
size to keep hard disks busy, and RAIDs usually have 64KB stripe sets or
bigger. But I don't know how scattered dirs in XFS are, or if you can
expect them to be sequential.
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-09-23 20:28 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-09-23 16:49 [PATCH] fix readahead calculations in xfs_dir2_leaf_getdents() Eric Sandeen
2009-09-23 18:42 ` Eric Sandeen
2009-09-23 20:29 ` Michael Monnerie [this message]
2009-09-25 19:42 ` [PATCH V2] " Eric Sandeen
2009-09-26 17:04 ` Christoph Hellwig
2009-09-26 18:03 ` Eric Sandeen
2009-10-07 22:22 ` Alex Elder
2009-10-07 22:24 ` Eric Sandeen
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=200909232229.03395@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