Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755375Ab1C3BoG (ORCPT ); Tue, 29 Mar 2011 21:44:06 -0400 Received: from ipmail07.adl2.internode.on.net ([150.101.137.131]:33147 "EHLO ipmail07.adl2.internode.on.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753785Ab1C3BoF (ORCPT ); Tue, 29 Mar 2011 21:44:05 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjoFAHeHkk15LK5JTmdsb2JhbAClUAsBASADIyW/cw2FXQQ Date: Wed, 30 Mar 2011 12:44:00 +1100 From: Dave Chinner To: Sean Noonan Cc: "'Christoph Hellwig'" , "'Michel Lespinasse'" , "'linux-kernel@vger.kernel.org'" , Martin Bligh , Trammell Hudson , Christos Zoulas , "'linux-xfs@oss.sgi.com'" , Stephen Degler , "'linux-mm@kvack.org'" Subject: Re: XFS memory allocation deadlock in 2.6.38 Message-ID: <20110330014400.GK3008@dastard> References: <20110324174311.GA31576@infradead.org> <081DDE43F61F3D43929A181B477DCA95639B5349@MSXAOA6.twosigma.com> <081DDE43F61F3D43929A181B477DCA95639B534E@MSXAOA6.twosigma.com> <081DDE43F61F3D43929A181B477DCA95639B5359@MSXAOA6.twosigma.com> <20110329192434.GA10536@infradead.org> <081DDE43F61F3D43929A181B477DCA95639B535D@MSXAOA6.twosigma.com> <20110330000942.GI3008@dastard> <081DDE43F61F3D43929A181B477DCA95639B5364@MSXAOA6.twosigma.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <081DDE43F61F3D43929A181B477DCA95639B5364@MSXAOA6.twosigma.com> User-Agent: Mutt/1.5.20 (2009-06-14) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 949 Lines: 27 On Tue, Mar 29, 2011 at 09:32:06PM -0400, Sean Noonan wrote: > > Ok, so that looks like root cause of the problem. can you try the > > patch below to see if it fixes the problem (without any other > > patches applied or reverted). > > It looks like this does fix the deadlock problem. However, it > appears to come at the price of significantly higher mmap startup > costs. It shouldn't make any difference to startup costs with the current code uses read faults to populate the region and that doesn't cause any allocation to occur and hence this code is not executed during the populate phase. Is this repeatable or is it just a one-off result? Cheers, Dave. -- Dave Chinner david@fromorbit.com -- 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/