From: Pekka Enberg Subject: Re: [BUG] fatal hang untarring 90GB file, possibly writeback related. Date: Tue, 10 May 2011 13:33:11 +0300 Message-ID: References: <20110428192104.GA4658@suse.de> <1304020767.2598.21.camel@mulgrave.site> <1304025145.2598.24.camel@mulgrave.site> <1304030629.2598.42.camel@mulgrave.site> <20110503091320.GA4542@novell.com> <1304431982.2576.5.camel@mulgrave.site> <1304432553.2576.10.camel@mulgrave.site> <20110506074224.GB6591@suse.de> <20110506080728.GC6591@suse.de> <1304964980.4865.53.camel@mulgrave.site> <20110510102141.GA4149@novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Cc: James Bottomley , Mel Gorman , Jan Kara , colin.king@canonical.com, Chris Mason , linux-fsdevel , linux-mm , linux-kernel , linux-ext4 , Christoph Lameter To: Mel Gorman Return-path: In-Reply-To: <20110510102141.GA4149@novell.com> Sender: owner-linux-mm@kvack.org List-Id: linux-ext4.vger.kernel.org On Tue, May 10, 2011 at 1:21 PM, Mel Gorman wrote: > It goes on. A number of filesystem and network paths are being hit > with high-order allocs. i915 was a red herring, it's present but not > in massive numbers. The filesystem, network and mempool allocations > are likely to be kicking kswapd awake frequently and hurting overall > system performance as a result. > > I really would like to hear if the fix makes a big difference or > if we need to consider forcing SLUB high-order allocations bailing > at the first sign of trouble (e.g. by masking out __GFP_WAIT in > allocate_slab). Even with the fix applied, kswapd might be waking up > less but processes will still be getting stalled in direct compaction > and direct reclaim so it would still be jittery. Yes, sounds reasonable to me. Pekka -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/ Don't email: email@kvack.org