[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <p73d4y2n7to.fsf@bingen.suse.de>
Date: 05 Aug 2007 02:28:19 +0200
From: Andi Kleen <andi@...stfloor.org>
To: Ingo Molnar <mingo@...e.hu>
Cc: Linus Torvalds <torvalds@...ux-foundation.org>,
Peter Zijlstra <a.p.zijlstra@...llo.nl>, linux-mm@...ck.org,
linux-kernel@...r.kernel.org, miklos@...redi.hu,
akpm@...ux-foundation.org, neilb@...e.de, dgc@....com,
tomoki.sekiyama.qu@...achi.com, nikita@...sterfs.com,
trond.myklebust@....uio.no, yingchao.zhou@...il.com,
richard@....demon.co.uk
Subject: Re: [PATCH 00/23] per device dirty throttling -v8
Ingo Molnar <mingo@...e.hu> writes:
> * Ingo Molnar <mingo@...e.hu> wrote:
>
> > [ my personal interest in this is the following regression: every time
> > i start a large kernel build with DEBUG_INFO on a quad-core 4GB RAM
> > box, i get up to 30 seconds complete pauses in Vim (and most other
> > tasks), during plain editing of the source code. (which happens when
> > Vim tries to write() to its swap/undo-file.) ]
>
> hm, it turns out that it's due to vim doing an occasional fsync not only
> on writeout, but during normal use too. "set nofsync" in the .vimrc
> solves this problem.
It should probably be doing fdatasync() instead. Then ext3 could just
write the data blocks only, but only mess with the logs when the file
size changed and mtime would be written out somewhat later.
[unless you have data logging enabled]
Does the problem go away when you change it to that?
-Andi
-
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/
Powered by blists - more mailing lists