linux-kernel - Re: ext3 IO latency measurements (was: Linux 2.6.29)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 26 Mar 2009 11:28:15 -0400
From:	Theodore Tso <tytso@....edu>
To:	Ingo Molnar <mingo@...e.hu>
Cc:	Jan Kara <jack@...e.cz>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Alan Cox <alan@...rguk.ukuu.org.uk>,
	Arjan van de Ven <arjan@...radead.org>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Nick Piggin <npiggin@...e.de>,
	Jens Axboe <jens.axboe@...cle.com>,
	David Rees <drees76@...il.com>, Jesper Krogh <jesper@...gh.cc>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Oleg Nesterov <oleg@...hat.com>,
	Roland McGrath <roland@...hat.com>
Subject: Re: ext3 IO latency measurements (was: Linux 2.6.29)

On Thu, Mar 26, 2009 at 03:03:12PM +0100, Ingo Molnar wrote:
> 
> I still see similarly bad latencies in Vim:
> 

When you say "similarly bad", how many seconds were you seeing?  I
understand that from the user's perspective, the 120 seconds you saw
with ext3 isn't going to be that different from 15 seconds (which
seems to be the maximum commit time in the jbd2 history file you sent
me), but I'm curious if what you saw was just as bad with ext4, or was
it somewhat better (i.e., 120 seconds vs 15 or so).  Or were you also
seeing a net time to save the file using vim of around 120 seconds
with ext4?

Ext4 in nodelalloc mode is mostly similar to ext3, but it does have
some improvements, such as a slightly elevated I/O priority for
kjournald, and the ext4's writepage doesn't take the journal handle as
it does in ext3.  (That's why I was confused about Linus's assertion
about ext3 waiting on the journal; ext4 doesn't any more, and I had
ext4 on the brain.)  Unfortunately, we don't have the
/proc/fs/jbd/<dev>/history for ext3, so it would be interesting to
compare whether the vim save latencies were improved or not with ext4.
If they are, then it might be worth Jan's time to fix up ext3's
writepage to not try request journal access if it's not needed.  It
might also be worth backporting ext4's slightly raised I/O priority
patch.

Another thing that's worth trying.  Suppose you use ionice to raise
the priority of kjournald to a real-time I/O priority (which is what
Arjan's patch does).  How much does that help?  Is it more or less
compared to what we're seeing with ext4's slightly reaised I/O
priority.

And if we mount the filesystem noatime, does that change the results
significantly as far as Vim write latencies and the jbd2 history file?

> The read-test is somewhat better. There are occasional blips of 4-5 
> seconds:

Presumably these go away once we mount the filesystem noatime, right?

	   	   	    	      	       - Ted
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/