[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20070508.232326.44096869.davem@davemloft.net>
Date: Tue, 08 May 2007 23:23:26 -0700 (PDT)
From: David Miller <davem@...emloft.net>
To: efault@....de
Cc: linux-kernel@...r.kernel.org
Subject: Re: multi-second freezes with current GIT?
From: Mike Galbraith <efault@....de>
Date: Wed, 09 May 2007 05:29:20 +0200
> On Tue, 2007-05-08 at 18:44 -0700, David Miller wrote:
> > I've been noticing this off and on for the past week or so.
> >
> > The system seems to jam up for several seconds, anything that would
> > need to read from disk just sits there during this time. I think it's
> > correlated with generating a lot of dirty write data.
> >
> > My mouse moves around in X etc. so it really is only processes that
> > need to read from disk that get stuck.
> >
> > Perhaps it's a side effect of those dirty ratio changes Linus made to
> > start off the 2.6.22 merge cycle?
>
> Uhoh, that seems highly likely.
>
> I think those changes may have been triggered by my repeatable and truly
> horrible system stalls when writing to an ext3 data=ordered nearly full
> filesystem. Anything that does fdatasync() and/or fsync() can cause
> very bad experiences indeed. KDE's little menu/program launcher
> doohickey does fdatasync() for some odd reason, which has utterly killed
> my entire GUI for up to and including 20 minutes at a whack.
>
> Switching to data=writeback cured those horrors. Lowering the dirty
> ratio reduced the agony of data=ordered tremendously, but didn't make it
> even remotely acceptable.
I'm using data=ordered on my partitions too.
-
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