From mboxrd@z Thu Jan 1 00:00:00 1970 From: Peter Zijlstra Subject: Re: [15/17] SLUB: Support virtual fallback via SLAB_VFALLBACK Date: Fri, 28 Sep 2007 19:55:19 +0200 Message-ID: <1191002119.18147.80.camel@lappy> References: <20070919033605.785839297@sgi.com> <20070919033643.763818012@sgi.com> <200709280742.38262.nickpiggin@yahoo.com.au> Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Cc: Nick Piggin , 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 pentafluge.infradead.org ([213.146.154.40]:36093 "EHLO pentafluge.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753280AbXI1R7U (ORCPT ); Fri, 28 Sep 2007 13:59:20 -0400 In-Reply-To: Sender: linux-fsdevel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org On Fri, 2007-09-28 at 10:33 -0700, Christoph Lameter wrote: > Again I have not seen any fallbacks to vmalloc in my testing. What we are > doing here is mainly to address your theoretical cases that we so far have > never seen to be a problem and increase the reliability of allocations of > page orders larger than 3 to a usable level. So far I have so far not > dared to enable orders larger than 3 by default. take a recent -mm kernel, boot with mem=128M. start 2 processes that each mmap a separate 64M file, and which does sequential writes on them. start a 3th process that does the same with 64M anonymous. wait for a while, and you'll see order=1 failures.