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.