Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756214AbZAVJdX (ORCPT ); Thu, 22 Jan 2009 04:33:23 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1754233AbZAVJdO (ORCPT ); Thu, 22 Jan 2009 04:33:14 -0500 Received: from courier.cs.helsinki.fi ([128.214.9.1]:46460 "EHLO mail.cs.helsinki.fi" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753644AbZAVJdN (ORCPT ); Thu, 22 Jan 2009 04:33:13 -0500 Subject: Re: [patch] SLQB slab allocator From: Pekka Enberg To: "Zhang, Yanmin" Cc: Christoph Lameter , Nick Piggin , Lin Ming , linux-mm@kvack.org, linux-kernel@vger.kernel.org, Andrew Morton , Linus Torvalds In-Reply-To: <1232616638.11429.131.camel@ymzhang> References: <84144f020901140645o68328e01ne0e10ace47555e19@mail.gmail.com> <20090114150900.GC25401@wotan.suse.de> <20090114152207.GD25401@wotan.suse.de> <84144f020901140730l747b4e06j41fb8a35daeaf6c8@mail.gmail.com> <20090114155923.GC1616@wotan.suse.de> <20090115061931.GC17810@wotan.suse.de> <20090116034356.GM17810@wotan.suse.de> <20090119061856.GB22584@wotan.suse.de> <1232616430.14549.11.camel@penberg-laptop> <1232616638.11429.131.camel@ymzhang> Date: Thu, 22 Jan 2009 11:33:12 +0200 Message-Id: <1232616792.14549.19.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 Content-Length: 2059 Lines: 42 On Thu, 2009-01-22 at 17:30 +0800, Zhang, Yanmin wrote: > On Thu, 2009-01-22 at 11:27 +0200, Pekka Enberg wrote: > > Hi Christoph, > > > > On Mon, 19 Jan 2009, Nick Piggin wrote: > > > > > > You only go to the allocator when the percpu queue goes empty though, so > > > > > > if memory policy changes (eg context switch or something), then subsequent > > > > > > allocations will be of the wrong policy. > > > > > > > > > > The per cpu queue size in SLUB is limited by the queues only containing > > > > > objects from the same page. If you have large queues like SLAB/SLQB(?) > > > > > then this could be an issue. > > > > > > > > And it could be a problem in SLUB too. Chances are that several allocations > > > > will be wrong after every policy switch. I could describe situations in which > > > > SLUB will allocate with the _wrong_ policy literally 100% of the time. > > > > On Wed, 2009-01-21 at 19:13 -0500, Christoph Lameter wrote: > > > No it cannot because in SLUB objects must come from the same page. > > > Multiple objects in a queue will only ever require a single page and not > > > multiple like in SLAB. > > > > There's one potential problem with "per-page queues", though. The bigger > > the object, the smaller the "queue" (i.e. less objects per page). Also, > > partial lists are less likely to help for big objects because they get > > emptied so quickly and returned to the page allocator. Perhaps we should > > do a small "full list" for caches with large objects? > That helps definitely. We could use a batch to control the list size. s/full list/empty list/g That is, a list of pages that could be returned to the page allocator but are pooled in SLUB to avoid the page allocator overhead. Note that this will not help allocators that trigger page allocator pass-through. Pekka -- 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/