lkml.org 
[lkml]   [2009]   [Apr]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [GIT PULL] Ext3 latency fixes


On Fri, 3 Apr 2009, Linus Torvalds wrote:
>
> The "overwrite" behavior may well be better, but it was smooth enough
> beforehand too (never having more than ~8MB dirty). The "create big file
> and sync" workload causes huge fsync pauses, though. IOW, try with
>
> while :
> do
> time sh -c "dd if=/dev/zero of=bigfile bs=8M count=256 ; sync"
> done
>
> and even really small fsync's end up being at the end of all that
> unrelated activity, and you see things like
>
> fsync(7) = 0 <32.756308>

Hmm. So I decided to try with "data=writeback" to see if it really makes
that big of a difference. It does help, but I still easily trigger
multi-second pauses:

fsync(4) = 0 <2.447926>
fsync(4) = 0 <4.275472>
fsync(4) = 0 <3.731948>
fsync(4) = 0 <4.020839>
fsync(6) = 0 <3.482735>
fsync(6) = 0 <5.819923>

even though the system _should_ be able to write back the 'bigfile'
datablocks without any ordering constraint on the fsync.

So at a guess, it now avoids some nasty journal writing ordering issue
where it has to wait for the previous transaction, and it's probably now
purely an IO ordering issue.

This is all with your ext3 work, btw. But I also added "rm bigfile" at the
end of the loop (so that it shouldn't trigge any "write out bigfile early"
logic), and that didn't seem to make any difference.

Are we perhaps ending up doing those regular 'bigfile' writes as
WRITE_SYNC, just because of the global "sync()" call? That's probably a
bad idea. A "sync" is about pure throughput. It's not about latency like
"fsync()" is.

Linus


\
 
 \ /
  Last update: 2009-04-03 22:47    [W:0.100 / U:0.816 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site