[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.LFD.0.999.0708040915360.5037@woody.linux-foundation.org>
Date: Sat, 4 Aug 2007 09:17:44 -0700 (PDT)
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Ingo Molnar <mingo@...e.hu>
cc: 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
On Sat, 4 Aug 2007, Ingo Molnar 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.
Yes, that's independent. The fact is, ext3 *sucks* at fsync. I hate hate
hate it. It's totally unusable, imnsho.
The whole point of fsync() is that it should sync only that one file, and
avoid syncing all the other stuff that is going on, and ext3 violates
that, because it ends up having to sync the whole log, or something like
that. So even if vim really wants to sync a small file, you end up waiting
for megabytes of data being written out.
I detest logging filesystems.
Linus
-
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