From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2992689AbXCBSHz (ORCPT ); Fri, 2 Mar 2007 13:07:55 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S2992691AbXCBSHz (ORCPT ); Fri, 2 Mar 2007 13:07:55 -0500 Received: from smtp.osdl.org ([65.172.181.24]:36459 "EHLO smtp.osdl.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2992689AbXCBSHy (ORCPT ); Fri, 2 Mar 2007 13:07:54 -0500 Date: Fri, 2 Mar 2007 10:06:19 -0800 From: Andrew Morton To: Rik van Riel Cc: Christoph Lameter , Mel Gorman , npiggin@suse.de, mingo@elte.hu, jschopp@austin.ibm.com, arjan@infradead.org, torvalds@linux-foundation.org, mbligh@mbligh.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: The performance and behaviour of the anti-fragmentation related patches Message-Id: <20070302100619.cec06d6a.akpm@linux-foundation.org> In-Reply-To: <45E8624E.2080001@redhat.com> References: <20070301101249.GA29351@skynet.ie> <20070301160915.6da876c5.akpm@linux-foundation.org> <45E842F6.5010105@redhat.com> <20070302085838.bcf9099e.akpm@linux-foundation.org> <20070302093501.34c6ef2a.akpm@linux-foundation.org> <45E8624E.2080001@redhat.com> X-Mailer: Sylpheed version 2.2.7 (GTK+ 2.8.6; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org On Fri, 02 Mar 2007 12:43:42 -0500 Rik van Riel wrote: > Andrew Morton wrote: > > On Fri, 2 Mar 2007 09:23:49 -0800 (PST) Christoph Lameter wrote: > > > >> On Fri, 2 Mar 2007, Andrew Morton wrote: > >> > >>>> Linux is *not* happy on 256GB systems. Even on some 32GB systems > >>>> the swappiness setting *needs* to be tweaked before Linux will even > >>>> run in a reasonable way. > >>> Please send testcases. > >> It is not happy if you put 256GB into one zone. > > > > Oh come on. What's the workload? What happens? system time? user time? > > kernel profiles? > > I can't share all the details, since a lot of the problems are customer > workloads. > > One particular case is a 32GB system with a database that takes most > of memory. The amount of actually freeable page cache memory is in > the hundreds of MB. Where's the rest of the memory? tmpfs? mlocked? hugetlb? > With swappiness at the default level of 60, kswapd > ends up eating most of a CPU, and other tasks also dive into the pageout > code. Even with swappiness as high as 98, that system still has > problems with the CPU use in the pageout code! > > Another typical problem is that people want to back up their database > servers. During the backup, parts of the working set get evicted from > the VM and performance is horrible. userspace fixes for this are far, far better than any magic goo the kernel can implement. We really need to get off our butts and start educating people. > A third scenario is where a system has way more RAM than swap, and not > a whole lot of freeable page cache. In this case, the VM ends up > spending WAY too much CPU time scanning and shuffling around essentially > unswappable anonymous memory and tmpfs files. Well we've allegedly fixed that, but it isn't going anywhere without testing.