From: Andreas Dilger <adilger@sun.com>
To: Eric Sandeen <sandeen@redhat.com>
Cc: ext4 development <linux-ext4@vger.kernel.org>
Subject: Re: delalloc is crippling fs_mark performance
Date: Mon, 21 Jul 2008 16:39:35 -0600 [thread overview]
Message-ID: <20080721223935.GC15203@webber.adilger.int> (raw)
In-Reply-To: <4884B7CF.7060800@redhat.com>
On Jul 21, 2008 11:22 -0500, Eric Sandeen wrote:
> Eric Sandeen wrote:
> > running fs_mark like this:
> >
> > fs_mark -d /mnt/test -D 256 -n 100000 -t 4 -s 20480 -F -S 0
> >
> > (256 subdirs, 100000 files/iteration, 4 threads, 20k files, no sync)
> >
> > on a 1T fs, with and without delalloc (mount option), is pretty interesting:
> >
> > http://people.redhat.com/esandeen/ext4/fs_mark.png
>
> I've updated this graph with another run where the group_prealloc
> tuneable was set to a perfect multiple of the allocation size, or 500
> blocks. This way the leftover 2-block preallocations don't wind up
> causing the list to grow with unuseable tiny leftover preallocations.
> After tuning this way, it does clearly seem to be the problem here.
Looking at that graph it would seem that allowing 1000 PAs to accumulate
with Aneesh's patch adds a constant slowdown. Compared with the "perfect"
case where the PA list is always empty it is noticably slower.
I'd guess that the right thing to do is have a few buckets for PAs of
different sizes, and keep them very short (e.g. <= 8) to avoid a lot of
list walking overhead on each access.
I think keeping a single PA of "each size" would likely run out if
different-sized allocations are being done, requiring a re-search.
Cheers, Andreas
--
Andreas Dilger
Sr. Staff Engineer, Lustre Group
Sun Microsystems of Canada, Inc.
next prev parent reply other threads:[~2008-07-21 22:39 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-07-18 16:11 delalloc is crippling fs_mark performance Eric Sandeen
2008-07-18 23:00 ` Eric Sandeen
2008-07-19 15:44 ` Eric Sandeen
2008-07-19 17:20 ` Theodore Tso
2008-07-21 9:37 ` Aneesh Kumar K.V
2008-07-21 16:22 ` Eric Sandeen
2008-07-21 22:39 ` Andreas Dilger [this message]
2008-07-22 11:11 ` Aneesh Kumar K.V
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=20080721223935.GC15203@webber.adilger.int \
--to=adilger@sun.com \
--cc=linux-ext4@vger.kernel.org \
--cc=sandeen@redhat.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.