Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753355AbYCJPw5 (ORCPT ); Mon, 10 Mar 2008 11:52:57 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751483AbYCJPwX (ORCPT ); Mon, 10 Mar 2008 11:52:23 -0400 Received: from relay2.sgi.com ([192.48.171.30]:57529 "EHLO relay.sgi.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1751145AbYCJPwQ (ORCPT ); Mon, 10 Mar 2008 11:52:16 -0400 Date: Mon, 10 Mar 2008 08:51:38 -0700 (PDT) From: Christoph Lameter X-X-Sender: clameter@schroedinger.engr.sgi.com To: Andi Kleen cc: Ingo Molnar , Thomas Gleixner , LKML , Linus Torvalds , Andrew Morton , Bart Van Assche , William Lee Irwin III , Benjamin Herrenschmidt , David Miller Subject: Re: quicklists confuse meminfo In-Reply-To: <87ejak12qx.fsf@basil.nowhere.org> Message-ID: References: <20080309111456.GA21690@elte.hu> <20080309120124.GB1249@elte.hu> <87ejak12qx.fsf@basil.nowhere.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1850 Lines: 37 On Sun, 9 Mar 2008, Andi Kleen wrote: > iirc quicklists were just to avoid rezeroing pages which are known to > be zero at free time (in theory __GFP_ZERO should handle that at > page_alloc.c level, but it doesn't) and to get a little private fast path > for the page allocator (might actually predate the current page_alloc > fast paths) Quicklists were introduced to increase performance of program termination and startup. The avoidance of zeroing is one effect. The other reason that made this a good optimization is the bad page allocator performance in general vs a simple LIFO list. The numbers that we saw on x86_64 were around a 90% reduction in overhead with the quicklists. The reason for the throttle is that termination and starting of large programs would have to zero large amounts of memory and go through the page allocator for all of this if the quicklists would be bounded to a fixed limit. Having a fraction of free memory allows preserving large amounts of page table pages for the next process that starts. Right now quicklists do not make much sense because the x86_64 portion was removed. IMHO The usefulness for i386 pgd/pud caching is negligible. The code came initially from IA64 arch code (I think it was first on sparc64 though). After it became available in the core it was used by various other arches. There have been a couple of people who wanted to continue work on quicklists (which made me focus on different things) but so far nothing has happened. Replacement of the i386 portion with alloc/free would be fairly straightforward I would think. -- 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/