[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20130318110136.GH10192@dhcp22.suse.cz>
Date: Mon, 18 Mar 2013 12:01:36 +0100
From: Michal Hocko <mhocko@...e.cz>
To: "K. Y. Srinivasan" <kys@...rosoft.com>
Cc: gregkh@...uxfoundation.org, linux-kernel@...r.kernel.org,
devel@...uxdriverproject.org, olaf@...fle.de, apw@...onical.com,
andi@...stfloor.org, akpm@...ux-foundation.org, linux-mm@...ck.org,
kamezawa.hiroyuki@...il.com, hannes@...xchg.org, yinghan@...gle.com
Subject: Re: [PATCH 2/2] Drivers: hv: balloon: Support 2M page allocations
for ballooning
On Mon 18-03-13 11:52:57, Michal Hocko wrote:
> On Sat 16-03-13 14:42:05, K. Y. Srinivasan wrote:
> > While ballooning memory out of the guest, attempt 2M allocations first.
> > If 2M allocations fail, then go for 4K allocations. In cases where we
> > have performed 2M allocations, split this 2M page so that we can free this
> > page at 4K granularity (when the host returns the memory).
>
> Maybe I am missing something but what is the advantage of 2M allocation
> when you split it up immediately so you are not using it as a huge page?
OK, it seems that Patch 1/2 says some advantages. That description
should be part of this patch IMO.
You are saying that a) it reduces fragmentation on the host b) it makes
ballooning more effective.
Have you measured any effects on the ability to allocate huge pages on
the host? What prevents from depleting high order pages on the host with
many guests? Also have you measured any effect on THP allocation success
rate on the host?
Could you clarify how this helps ballooning when you split the page
right after you allocate it?
--
Michal Hocko
SUSE Labs
--
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