[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <200709290622.11019.nickpiggin@yahoo.com.au>
Date: Sat, 29 Sep 2007 06:22:10 +1000
From: Nick Piggin <nickpiggin@...oo.com.au>
To: Christoph Lameter <clameter@....com>
Cc: Peter Zijlstra <a.p.zijlstra@...llo.nl>,
Christoph Hellwig <hch@....de>, Mel Gorman <mel@...net.ie>,
linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org,
David Chinner <dgc@....com>, Jens Axboe <jens.axboe@...cle.com>
Subject: Re: [15/17] SLUB: Support virtual fallback via SLAB_VFALLBACK
On Saturday 29 September 2007 04:41, Christoph Lameter wrote:
> 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?
Yeah, you could do that, but we generally don't have big problems allocating
stacks in mainline, because we have very few users of higher order pages,
the few that are there don't seem to be a problem.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists