[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <5277D7EA.9000801@citrix.com>
Date: Mon, 4 Nov 2013 17:22:50 +0000
From: David Vrabel <david.vrabel@...rix.com>
To: Bob Liu <lliubbo@...il.com>
CC: <konrad.wilk@...cle.com>, <xen-devel@...ts.xenproject.org>,
Bob Liu <bob.liu@...cle.com>, <linux-kernel@...r.kernel.org>
Subject: Re: [Xen-devel] [PATCH] drivers: xen-selfballoon: consider slab pages
On 04/11/13 12:39, Bob Liu wrote:
> Currently the goal_page in xen-selfballon doesn't consider much about pages used
> in kernel space.
> A typical usage is slab pages, without consider slab pages the goal_page result
> may be too rough and lead extra memory pressure to guest os.
Can you provide some real world figures where the calculatation got it
wrong? What was the resultant behavior? Swap death? OOM killer?
> Signed-off-by: Bob Liu <bob.liu@...cle.com>
> ---
> drivers/xen/xen-selfballoon.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/xen/xen-selfballoon.c b/drivers/xen/xen-selfballoon.c
> index 21e18c1..4814759 100644
> --- a/drivers/xen/xen-selfballoon.c
> +++ b/drivers/xen/xen-selfballoon.c
> @@ -191,6 +191,8 @@ static void selfballoon_process(struct work_struct *work)
> tgt_pages = cur_pages; /* default is no change */
> goal_pages = vm_memory_committed() +
> totalreserve_pages +
> + global_page_state(NR_SLAB_RECLAIMABLE) +
Does SLAB_RECLAIMABLE want to be included here? Unless I'm
misunderstanding here, SLAB_RECLAIMABLE is effectively free.
> + global_page_state(NR_SLAB_UNRECLAIMABLE) +
This bit looks fine to me.
> MB2PAGES(selfballoon_reserved_mb);
> #ifdef CONFIG_FRONTSWAP
> /* allow space for frontswap pages to be repatriated */
David
--
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