Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753588Ab0KGR1q (ORCPT ); Sun, 7 Nov 2010 12:27:46 -0500 Received: from swampdragon.chaosbits.net ([90.184.90.115]:19843 "EHLO swampdragon.chaosbits.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752846Ab0KGR1o (ORCPT ); Sun, 7 Nov 2010 12:27:44 -0500 Date: Sun, 7 Nov 2010 18:16:26 +0100 (CET) From: Jesper Juhl To: Dave Chinner cc: Chris Mason , Ingo Molnar , Pekka Enberg , Aidar Kultayev , linux-kernel@vger.kernel.org, linux-mm@kvack.org, Linus Torvalds , Andrew Morton , Jens Axboe , Peter Zijlstra , Nick Piggin , Arjan van de Ven , Thomas Gleixner , "Ted Ts'o" , Corrado Zoccolo , Shaohua Li , Sanjoy Mahajan , Steven Barrett Subject: Re: 2.6.36 io bring the system to its knees In-Reply-To: <20101105014334.GF13830@dastard> Message-ID: References: <20101028090002.GA12446@elte.hu> <20101028133036.GA30565@elte.hu> <20101028170132.GY27796@think> <20101105014334.GF13830@dastard> User-Agent: Alpine 2.00 (LNX 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3777 Lines: 87 On Fri, 5 Nov 2010, Dave Chinner wrote: > 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. > Some details below. [jj@dragon ~]$ mount proc on /proc type proc (rw,relatime) sys on /sys type sysfs (rw,relatime) udev on /dev type devtmpfs (rw,nosuid,relatime,size=10240k,nr_inodes=255749,mode=755) /dev/disk/by-uuid/61d104a5-4f7b-40ef-a9c8-44ad2765513e on / type ext4 (rw,commit=0) devpts on /dev/pts type devpts (rw) shm on /dev/shm type tmpfs (rw,nosuid,nodev) [root@dragon ~]# hdparm -v /dev/disk/by-uuid/61d104a5-4f7b-40ef-a9c8-44ad2765513e /dev/disk/by-uuid/61d104a5-4f7b-40ef-a9c8-44ad2765513e: multcount = 16 (on) IO_support = 1 (32-bit) readonly = 0 (off) readahead = 256 (on) geometry = 9729/255/63, sectors = 25220160, start = 119644560 [root@dragon ~]# dmesg | grep -i ext4 EXT4-fs (sda4): mounted filesystem with ordered data mode. Opts: (null) EXT4-fs (sda4): re-mounted. Opts: (null) EXT4-fs (sda4): re-mounted. Opts: (null) EXT4-fs (sda4): re-mounted. Opts: commit=0 The elevator in use is CFQ. The app that's causing the system to behave this way (the 'pacman' package manager in Arch Linux) makes a few calls (2-4) to fsync() during its run, but that's all. -- Jesper Juhl http://www.chaosbits.net/ Plain text mails only, please http://www.expita.com/nomime.html Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/