From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751062Ab0CLDcL (ORCPT ); Thu, 11 Mar 2010 22:32:11 -0500 Received: from cpsmtpm-eml104.kpnxchange.com ([195.121.3.8]:58385 "EHLO CPSMTPM-EML104.kpnxchange.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750721Ab0CLDcJ (ORCPT ); Thu, 11 Mar 2010 22:32:09 -0500 From: Frans Pop To: Mel Gorman Subject: Re: Memory management woes - order 1 allocation failures Date: Fri, 12 Mar 2010 04:32:03 +0100 User-Agent: KMail/1.9.9 Cc: Greg KH , KOSAKI Motohiro , Pekka Enberg , Christoph Lameter , linux-kernel@vger.kernel.org, linux-mm@kvack.org, Alan Cox References: <20100302221751.20addf02@lxorguk.ukuu.org.uk> <20100302222933.GF11355@csn.ul.ie> In-Reply-To: <20100302222933.GF11355@csn.ul.ie> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <201003120432.06149.elendil@planet.nl> X-OriginalArrivalTime: 12 Mar 2010 03:32:06.0804 (UTC) FILETIME=[971CAD40:01CAC194] Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tuesday 02 March 2010, Mel Gorman wrote: > On Tue, Mar 02, 2010 at 10:17:51PM +0000, Alan Cox wrote: > > > -#define TTY_BUFFER_PAGE ((PAGE_SIZE - 256) / 2) > > > +#define TTY_BUFFER_PAGE (((PAGE_SIZE - sizeof(struct tty_buffer)) / > > > 2) & ~0xFF) > > > > Yes agreed I missed a '-1' > > Frans, would you mind testing your NAS box with the following patch > applied please? It should apply cleanly on top of 2.6.33-rc7. Thanks Thanks Mel. I've been running with this patch for about a week now and have so far not seen any more allocation failures. I've tried doing large rsyncs a few times. It's not 100% conclusive, but I would say it improves things and I've certainly not noticed any issues with the patch. Before I got the patch I noticed that the default value for vm.min_free_kbytes was only 1442 for this machine. Isn't that on the low side? Could that have been a factor? My concern is that, although fixing bugs in GFP_ATOMIC allocations is certainly very good, I can't help wondering why the system does not keep a bit more memory in reserve instead of using everything up for relatively silly things like cache and buffers. What if during an rsync I plug in some USB device whose driver has some valid GFP_ATOMIC allocations? Shouldn't the memory manager allow for such situations? Cheers, FJP > tty: Keep the default buffering to sub-page units > > We allocate during interrupts so while our buffering is normally diced > up small anyway on some hardware at speed we can pressure the VM > excessively for page pairs. We don't really need big buffers to be > linear so don't try so hard. > > In order to make this work well we will tidy up excess callers to > request_room, which cannot itself enforce this break up. > > [mel@csn.ul.ie: Adjust TTY_BUFFER_PAGE to take padding into account] > Signed-off-by: Alan Cox > Signed-off-by: Greg Kroah-Hartman Tested-by: Frans Pop