[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20090420092604.GB14699@duck.suse.cz>
Date: Mon, 20 Apr 2009 11:26:04 +0200
From: Jan Kara <jack@...e.cz>
To: Mike Galbraith <efault@....de>
Cc: Amit Shah <amit.shah@...hat.com>, Theodore Tso <tytso@....edu>,
Chris Mason <chris.mason@...cle.com>, Jan Kara <jack@...e.cz>,
Linus Torvalds <torvalds@...ux-foundation.org>,
Linux Kernel Developers List <linux-kernel@...r.kernel.org>,
Ext4 Developers List <linux-ext4@...r.kernel.org>
Subject: Re: [PATCH] Add ext3 data=guarded mode
On Mon 20-04-09 11:07:17, Mike Galbraith wrote:
> On Sun, 2009-04-19 at 11:54 +0530, Amit Shah wrote:
> > On (Sat) Apr 18 2009 [09:28:21], Mike Galbraith wrote:
>
> > > Probably because you're swapping heavily, and that is perturbing your
> >
> > The variance only affects the 4k test; the other times more or less
> > remain the same.
>
> My box disagrees.
>
> (bumps ulimits to test 4BG... OS+swap live on sdb btw)
>
> ./test-file-zero-alloc-speed 4 /dev/sdf3 /media/root ext3 rw,_netdev,noatime,data=foo,acl,user_xattr
>
> foo=guarded
> 4k 225 141 80 142 361
> 8k 74 96 362 78 84
> mm 55 57 57 57 57
>
> foo=writeback
> 4k 179 264 187 125 93
> 8k 94 161 73 334 84
> mm 57 58 57 56 57
>
> foo=ordered
> 4k 81 74 76 80 75
> 8k 77 76 224 79 79
> mm 59 56 60 58 59
>
> foo=journal
> 4k 95 297 69 83 420
> 8k 73 139 158 80 78
> mm 57 58 56 59 56
>
> ./test-file-zero-alloc-speed 2 /dev/sdf3 /media/root ext3 rw,_netdev,noatime,data=foo,acl,user_xattr
>
> foo=guarded
> 4k 28 27 27 28 28
> 8k 28 27 27 28 27
>
> foo=writeback
> 4k 27 27 27 27 27
> 8k 28 28 27 27 28
>
> All journal modes seem subject to bad throughput under heavy pressure,
> though data=ordered seems much less likely to suffer for some reason.
> Major difference _seems_ to be that write()+largefile induces very much
> swap activity.
My rough guess is that this depends on the VM writeout behavior. In
ordered mode, we forcibly writeout all the dirty data on a transaction
commit which happens every 5 seconds so they don't accumulate that much.
In other journaling modes we don't do that and decisions about writeout
(probably how much pdflush manages to write in background vs. how much
VM throttles the process to do the writeback itself) cause variances in
the run time. But this is just a guess. You could gather blktraces of
slow and fast runs and then look if the amount of IO done by different
processes significantly differs. If Chris has merged by improvements to
Seekwatcher, then you could nicely visualize this (hmm, that doesn't seem
to be the case so I'm attaching the diff and a helper script - see comments
in the beginning of the script and command helps for usage).
Honza
--
Jan Kara <jack@...e.cz>
SUSE Labs, CR
View attachment "seekwatcher-tagging.diff" of type "text/x-patch" (15123 bytes)
View attachment "tag-by-process" of type "text/plain" (2649 bytes)
Powered by blists - more mailing lists