[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <45EC352A.7060802@austin.ibm.com>
Date: Mon, 05 Mar 2007 09:20:10 -0600
From: Joel Schopp <jschopp@...tin.ibm.com>
To: Nick Piggin <npiggin@...e.de>
CC: Linus Torvalds <torvalds@...ux-foundation.org>,
Andrew Morton <akpm@...ux-foundation.org>,
Mel Gorman <mel@...net.ie>, clameter@...r.sgi.com,
mingo@...e.hu, arjan@...radead.org, mbligh@...igh.org,
linux-mm@...ck.org, linux-kernel@...r.kernel.org
Subject: Re: The performance and behaviour of the anti-fragmentation related
patches
> But if you don't require a lot of higher order allocations anyway, then
> guest fragmentation caused by ballooning doesn't seem like much problem.
If you only need to allocate 1 page size and smaller allocations then no it's not a
problem. As soon as you go above that it will be. You don't need to go all the way
up to MAX_ORDER size to see an impact, it's just increasingly more severe as you get
away from 1 page and towards MAX_ORDER.
>
> If you need higher order allocations, then ballooning is bad because of
> fragmentation, so you need memory unplug, so you need higher order
> allocations. Goto 1.
Yes, it's a closed loop. But hotplug isn't the only one that needs higher order
allocations. In fact it's pretty far down the list. I look at it like this, a lot
of users need high order allocations for better performance and things like on-demand
hugepages. As a bonus you get memory hot-remove.
> Balooning probably does skew memory management stats and watermarks, but
> that's just because it is implemented as a module. A couple of hooks
> should be enough to allow things to be adjusted?
That is a good idea independent of the current discussion.
-
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