From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756708AbZBFI5n (ORCPT ); Fri, 6 Feb 2009 03:57:43 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1752090AbZBFI5d (ORCPT ); Fri, 6 Feb 2009 03:57:33 -0500 Received: from courier.cs.helsinki.fi ([128.214.9.1]:36320 "EHLO mail.cs.helsinki.fi" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752068AbZBFI5c (ORCPT ); Fri, 6 Feb 2009 03:57:32 -0500 Subject: Re: [patch] SLQB slab allocator From: Pekka Enberg To: Hugh Dickins Cc: "Zhang, Yanmin" , Nick Piggin , Linux Memory Management List , Linux Kernel Mailing List , Andrew Morton , Lin Ming , Christoph Lameter In-Reply-To: References: <20090121143008.GV24891@wotan.suse.de> <84144f020901220201g6bdc2d5maf3395fc8b21fe67@mail.gmail.com> <1233545923.2604.60.camel@ymzhang> <1233565214.17835.13.camel@penberg-laptop> <1233646145.2604.137.camel@ymzhang> <1233714090.2604.186.camel@ymzhang> Date: Fri, 06 Feb 2009 10:57:29 +0200 Message-Id: <1233910649.29891.26.camel@penberg-laptop> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit X-Mailer: Evolution 2.22.3.1 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Hugh, On Thu, 2009-02-05 at 19:04 +0000, Hugh Dickins wrote: > I then tried a patch I thought obviously better than yours: just mask > off __GFP_WAIT in that __GFP_NOWARN|__GFP_NORETRY preliminary call to > alloc_slab_page(): so we're not trying to infer anything about high- > order availability from the number of free order-0 pages, but actually > going to look for it and taking it if it's free, forgetting it if not. > > That didn't work well at all: almost as bad as the unmodified slub.c. > I decided that was due to __alloc_pages_internal()'s > wakeup_kswapd(zone, order): just expressing an interest in a high- > order page was enough to send it off trying to reclaim them, though > not directly. Hacked in a condition to suppress that in this case: > worked a lot better, but not nearly as well as yours. I supposed > that was somehow(?) due to the subsequent get_page_from_freelist() > calls with different watermarking: hacked in another __GFP flag to > break out to nopage just like the NUMA_BUILD GFP_THISNODE case does. > Much better, getting close, but still not as good as yours. Did you look at it with oprofile? One thing to keep in mind is that if there are 4K allocations going on, your approach will get double the overhead of page allocations (which can be substantial performance hit for slab). Pekka