From: Nick Piggin Subject: Re: [15/17] SLUB: Support virtual fallback via SLAB_VFALLBACK Date: Tue, 2 Oct 2007 18:43:14 +1000 Message-ID: <200710021843.15241.nickpiggin@yahoo.com.au> References: <20070919033605.785839297@sgi.com> <200709281514.48293.nickpiggin@yahoo.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Cc: Christoph Hellwig , Mel Gorman , linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, David Chinner , Jens Axboe To: Christoph Lameter Return-path: Received: from smtp102.mail.mud.yahoo.com ([209.191.85.212]:39695 "HELO smtp102.mail.mud.yahoo.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with SMTP id S1752374AbXJCBOq (ORCPT ); Tue, 2 Oct 2007 21:14:46 -0400 In-Reply-To: Content-Disposition: inline Sender: linux-fsdevel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org On Tuesday 02 October 2007 06:50, Christoph Lameter wrote: > On Fri, 28 Sep 2007, Nick Piggin wrote: > > I thought it was slower. Have you fixed the performance regression? > > (OK, I read further down that you are still working on it but not > > confirmed yet...) > > The problem is with the weird way of Intel testing and communication. > Every 3-6 month or so they will tell you the system is X% up or down on > arch Y (and they wont give you details because its somehow secret). And > then there are conflicting statements by the two or so performance test > departments. One of them repeatedly assured me that they do not see any > regressions. Just so long as there aren't known regressions that would require higher order allocations to fix them. > > OK, so long as it isn't going to depend on using higher order pages, > > that's fine. (if they help even further as an optional thing, that's fine > > too. You can turn them on your huge systems and not even bother about > > adding this vmap fallback -- you won't have me to nag you about these > > purely theoretical issues). > > Well the vmap fallback is generally useful AFAICT. Higher order > allocations are common on some of our platforms. Order 1 failures even > affect essential things like stacks that have nothing to do with SLUB and > the LBS patchset. I don't know if it is worth the trouble, though. The best thing to do is to ensure that contiguous memory is not wasted on frivolous things... a few order-1 or 2 allocations aren't too much of a problem. The only high order allocation failure I've seen from fragmentation for a long time IIRC are the order-3 failures coming from e1000. And obviously they cannot use vmap.