From mboxrd@z Thu Jan 1 00:00:00 1970 From: Christoph Lameter Subject: Re: [15/17] SLUB: Support virtual fallback via SLAB_VFALLBACK Date: Fri, 28 Sep 2007 11:41:18 -0700 (PDT) Message-ID: References: <20070919033605.785839297@sgi.com> <20070919033643.763818012@sgi.com> <200709280742.38262.nickpiggin@yahoo.com.au> <1191002119.18147.80.camel@lappy> <1191003950.18147.85.camel@lappy> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: Nick Piggin , Christoph Hellwig , Mel Gorman , linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, David Chinner , Jens Axboe To: Peter Zijlstra Return-path: In-Reply-To: <1191003950.18147.85.camel@lappy> Sender: linux-kernel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org On Fri, 28 Sep 2007, Peter Zijlstra wrote: > memory got massively fragemented, as anti-frag gets easily defeated. > setting min_free_kbytes to 12M does seem to solve it - it forces 2 max > order blocks to stay available, so we don't mix types. however 12M on > 128M is rather a lot. Yes, strict ordering would be much better. On NUMA it may be possible to completely forbid merging. We can fall back to other nodes if necessary. 12M is not much on a NUMA system. But this shows that (unsurprisingly) we may have issues on systems with a small amounts of memory and we may not want to use higher orders on such systems. The case you got may be good to use as a testcase for the virtual fallback. Hmmmm... Maybe it is possible to allocate the stack as a virtual compound page. Got some script/code to produce that problem?