Re: 2.6.36 io bring the system to its knees

[Dave Chinner]

On Fri, Nov 05, 2010 at 12:48:17AM +0100, Jesper Juhl wrote:
> On Fri, 5 Nov 2010, Jesper Juhl wrote:
> 
> > On Thu, 28 Oct 2010, Chris Mason wrote:
> > 
> > > On Thu, Oct 28, 2010 at 03:30:36PM +0200, Ingo Molnar wrote:
> > > > 
> > > > "Many seconds freezes" and slowdowns wont be fixed via the VFS scalability patches 
> > > > i'm afraid.
> > > > 
> > > > This has the appearance of some really bad IO or VM latency problem. Unfixed and 
> > > > present in stable kernel versions going from years ago all the way to v2.6.36.
> > > 
> > > Hmmm, the workload you're describing here has two special parts.  First
> > > it dramatically overloads the disk, and then it has guis doing things
> > > waiting for the disk.
> > > 
> > 
> > Just want to chime in with a 'me too'.
> > 
> > I see something similar on Arch Linux when doing 'pacman -Syyuv' and there 
> > are many (as in more than 5-10) updates to apply. While the update is 
> > running (even if that's all the system is doing) system responsiveness is 
> > terrible - just starting 'chromium' which is usually instant (at least 
> > less than 2 sec at worst) can take upwards of 10 seconds and the mouse 
> > cursor in X starts to jump a bit as well and switching virtual desktops 
> > noticably lags when redrawing the new desktop if there's a full screen app 
> > like gimp or OpenOffice open there. This is on a Lenovo Thinkpad R61i 
> > which has a 'Intel(R) Core(TM)2 Duo CPU T7250 @ 2.00GHz' CPU, 2GB of 
> > memory and 499996 kilobytes of swap.
> > 
> Forgot to mention the kernel I currently experience this with : 
> 
> [jj@dragon ~]$ uname -a
> Linux dragon 2.6.35-ARCH #1 SMP PREEMPT Sat Oct 30 21:22:26 CEST 2010 x86_64 Intel(R) Core(TM)2 Duo CPU T7250 @ 2.00GHz GenuineIntel GNU/Linux

I think anyone reporting a interactivity problem also needs to
indicate what their filesystem is, what mount paramters they are
using, what their storage config is, whether barriers are active or
not, what elevator they are using, whether one or more of the
applications are issuing fsync() or sync() calls, and so on.

Basically, what we need to know is whether these problems are
isolated to a particular filesystem or storage type because
they may simply be known problems (e.g. the ext3 fsync-the-world
problem).

Cheers,

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