From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S965010AbXCDB70 (ORCPT ); Sat, 3 Mar 2007 20:59:26 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S932636AbXCDB70 (ORCPT ); Sat, 3 Mar 2007 20:59:26 -0500 Received: from mx1.redhat.com ([66.187.233.31]:60223 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932240AbXCDB7Z (ORCPT ); Sat, 3 Mar 2007 20:59:25 -0500 Message-ID: <45EA27BD.7080909@redhat.com> Date: Sat, 03 Mar 2007 20:58:21 -0500 From: Rik van Riel Organization: Red Hat, Inc User-Agent: Thunderbird 1.5.0.7 (X11/20061008) MIME-Version: 1.0 To: Andrew Morton CC: Nick Piggin , Christoph Lameter , Mel Gorman , 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 References: <20070302050625.GD15867@wotan.suse.de> <20070302054944.GE15867@wotan.suse.de> <20070302060831.GF15867@wotan.suse.de> <20070302062950.GG15867@wotan.suse.de> <20070302071955.GA5557@wotan.suse.de> <20070302081210.GD5557@wotan.suse.de> <45EA2037.9060303@redhat.com> <20070303175158.00d867cb.akpm@linux-foundation.org> In-Reply-To: <20070303175158.00d867cb.akpm@linux-foundation.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Andrew Morton wrote: > On Sat, 03 Mar 2007 20:26:15 -0500 Rik van Riel wrote: >> Nick Piggin wrote: >> >>> Different issue, isn't it? Rik wants to be smarter in figuring out which >>> pages to throw away. More work per page == worse for you. >> Being smarter about figuring out which pages to evict does >> not equate to spending more work. One big component is >> sorting the pages beforehand, so we do not end up scanning >> through (and randomizing the LRU order of) anonymous pages >> when we do not want to, or cannot, evict them anyway. >> > > My gut feel is that we could afford to expend a lot more cycles-per-page > doing stuff to avoid IO than we presently do. In general, yes. In the specific "128GB RAM, 90GB anon/shm/... and 2GB swap" case, no :) > At least, reclaim normally just doesn't figure in system CPU time, except > for when it's gone completely stupid. > > It could well be that we sleep too much in there though. It's all about minimizing IO, I suspect. Not just the total amount of IO though, also the amount of pageout IO that's in flight at once, so we do not introduce stupidly high latencies. -- Politics is the struggle between those who want to make their country the best in the world, and those who believe it already is. Each group calls the other unpatriotic. From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <45EA27BD.7080909@redhat.com> Date: Sat, 03 Mar 2007 20:58:21 -0500 From: Rik van Riel MIME-Version: 1.0 Subject: Re: The performance and behaviour of the anti-fragmentation related patches References: <20070302050625.GD15867@wotan.suse.de> <20070302054944.GE15867@wotan.suse.de> <20070302060831.GF15867@wotan.suse.de> <20070302062950.GG15867@wotan.suse.de> <20070302071955.GA5557@wotan.suse.de> <20070302081210.GD5557@wotan.suse.de> <45EA2037.9060303@redhat.com> <20070303175158.00d867cb.akpm@linux-foundation.org> In-Reply-To: <20070303175158.00d867cb.akpm@linux-foundation.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-mm@kvack.org Return-Path: To: Andrew Morton Cc: Nick Piggin , Christoph Lameter , Mel Gorman , 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 List-ID: Andrew Morton wrote: > On Sat, 03 Mar 2007 20:26:15 -0500 Rik van Riel wrote: >> Nick Piggin wrote: >> >>> Different issue, isn't it? Rik wants to be smarter in figuring out which >>> pages to throw away. More work per page == worse for you. >> Being smarter about figuring out which pages to evict does >> not equate to spending more work. One big component is >> sorting the pages beforehand, so we do not end up scanning >> through (and randomizing the LRU order of) anonymous pages >> when we do not want to, or cannot, evict them anyway. >> > > My gut feel is that we could afford to expend a lot more cycles-per-page > doing stuff to avoid IO than we presently do. In general, yes. In the specific "128GB RAM, 90GB anon/shm/... and 2GB swap" case, no :) > At least, reclaim normally just doesn't figure in system CPU time, except > for when it's gone completely stupid. > > It could well be that we sleep too much in there though. It's all about minimizing IO, I suspect. Not just the total amount of IO though, also the amount of pageout IO that's in flight at once, so we do not introduce stupidly high latencies. -- Politics is the struggle between those who want to make their country the best in the world, and those who believe it already is. Each group calls the other unpatriotic. -- 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/ . Don't email: email@kvack.org