Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1760448AbZF3ADX (ORCPT ); Mon, 29 Jun 2009 20:03:23 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1760327AbZF3ADA (ORCPT ); Mon, 29 Jun 2009 20:03:00 -0400 Received: from smtp-out.google.com ([216.239.33.17]:38014 "EHLO smtp-out.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1760421AbZF3AC6 (ORCPT ); Mon, 29 Jun 2009 20:02:58 -0400 DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=date:from:x-x-sender:to:cc:subject:in-reply-to:message-id: references:user-agent:mime-version:content-type:x-system-of-record; b=sbO7VdCnzz2uiGN1tuiqO8ZlmyHh+0XV22etLY5DX3nkXunIZjr33G/1+/ydFhiCt +bPs8PoU+N1BiFVMtYaRA== Date: Mon, 29 Jun 2009 17:02:55 -0700 (PDT) From: David Rientjes X-X-Sender: rientjes@chino.kir.corp.google.com To: Justin Piszcz cc: Linux Kernel Mailing List , Kernel Testers List , "Rafael J. Wysocki" , Rik van Riel Subject: Re: [Bug #13648] nfsd: page allocation failure In-Reply-To: <5Hhc7UkUKEO.A.KGF.HjASKB@chimera> Message-ID: References: <5Hhc7UkUKEO.A.KGF.HjASKB@chimera> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-System-Of-Record: true Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1324 Lines: 30 On Mon, 29 Jun 2009, Rafael J. Wysocki wrote: > This message has been generated automatically as a part of a report > of regressions introduced between 2.6.29 and 2.6.30. > > The following bug entry is on the current list of known regressions > introduced between 2.6.29 and 2.6.30. Please verify if it still should > be listed and let me know (either way). > > > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13648 > Subject : nfsd: page allocation failure > Submitter : Justin Piszcz > Date : 2009-06-22 12:08 (7 days old) > References : http://lkml.org/lkml/2009/6/22/309 > I'd be interested to hear from Justin if reducing /proc/sys/vm/dirty_background_ratio as I earlier suggested helps. ZONE_NORMAL isn't much larger than ZONE_DMA32 on this machine and both lowmem zones have an abundance of free memory which suggests pdflush's ratio isn't being met to commence background writeout while at the same time ZONE_NORMAL is being depleted as the result of constant nfs GFP_ATOMIC allocations that cannot try direct reclaim. -- 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/