From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail144.messagelabs.com (mail144.messagelabs.com [216.82.254.51]) by kanga.kvack.org (Postfix) with SMTP id A16D65F0001 for ; Tue, 3 Feb 2009 02:29:17 -0500 (EST) Subject: Re: [patch] SLQB slab allocator From: "Zhang, Yanmin" In-Reply-To: <1233565214.17835.13.camel@penberg-laptop> References: <20090121143008.GV24891@wotan.suse.de> <84144f020901220201g6bdc2d5maf3395fc8b21fe67@mail.gmail.com> <1233545923.2604.60.camel@ymzhang> <1233565214.17835.13.camel@penberg-laptop> Content-Type: text/plain; charset=UTF-8 Date: Tue, 03 Feb 2009 15:29:05 +0800 Message-Id: <1233646145.2604.137.camel@ymzhang> Mime-Version: 1.0 Content-Transfer-Encoding: 8bit Sender: owner-linux-mm@kvack.org To: Pekka Enberg Cc: Hugh Dickins , Nick Piggin , Linux Memory Management List , Linux Kernel Mailing List , Andrew Morton , Lin Ming , Christoph Lameter List-ID: On Mon, 2009-02-02 at 11:00 +0200, Pekka Enberg wrote: > Hi Yanmin, > > On Mon, 2009-02-02 at 11:38 +0800, Zhang, Yanmin wrote: > > Can we add a checking about free memory page number/percentage in function > > allocate_slab that we can bypass the first try of alloc_pages when memory > > is hungry? > > If the check isn't too expensive, I don't any reason not to. How would > you go about checking how much free pages there are, though? Is there > something in the page allocator that we can use for this? i>>?We can use nr_free_pages(), totalram_pages and hugetlb_total_pages(). Below patch is a try. I tested it with hackbench and tbench on my stoakley (2 qual-core processors) and tigerton (4 qual-core processors). There is almost no regression. Besides this patch, I have another patch to try to reduce the calculation of "i>>?totalram_pages - hugetlb_total_pages()", but it touches many files. So just post the first simple patch here for review. Hugh, Would you like to test it on your machines? Thanks, Yanmin --- --- linux-2.6.29-rc2/mm/slub.c 2009-01-20 14:20:45.000000000 +0800 +++ linux-2.6.29-rc2_slubfreecheck/mm/slub.c 2009-02-03 14:40:52.000000000 +0800 @@ -23,6 +23,8 @@ #include #include #include +#include +#include #include #include @@ -1076,14 +1078,18 @@ static inline struct page *alloc_slab_pa static struct page *allocate_slab(struct kmem_cache *s, gfp_t flags, int node) { - struct page *page; + struct page *page = NULL; struct kmem_cache_order_objects oo = s->oo; + unsigned long free_pages = nr_free_pages(); + unsigned long total_pages = totalram_pages - hugetlb_total_pages(); flags |= s->allocflags; - page = alloc_slab_page(flags | __GFP_NOWARN | __GFP_NORETRY, node, - oo); - if (unlikely(!page)) { + if (free_pages > total_pages >> 3) { + page = alloc_slab_page(flags | __GFP_NOWARN | __GFP_NORETRY, + node, oo); + } + if (!page) { oo = s->min; /* * Allocation may have failed due to fragmentation. -- 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