Date: Wed, 17 Nov 2010 13:17:57 +0000 (UTC) From: "Bjoern A. Zeeb" <bzeeb-lists@lists.zabbadoz.net> To: Marko Zec <zec@icir.org> Cc: FreeBSD virtualization mailing list <freebsd-virtualization@freebsd.org> Subject: Re: VIMAGE: Freed UMA keg was not empty Message-ID: <20101117131438.I24596@maildrop.int.zabbadoz.net> In-Reply-To: <201011171345.06789.zec@icir.org> References: <201011170627.28025.thierry.herbelot@free.fr> <20101117055208.S24596@maildrop.int.zabbadoz.net> <201011171345.06789.zec@icir.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 17 Nov 2010, Marko Zec wrote:
> Actually, we never seriously discussed or revisited the issue with separate
> UMA pools for each vnet instance.
>
> My original motivation when O introduced separate UMA pools was primarily in
> making it easier to spot resource leaks, and to prove the correctness of the
> whole VIMAGE / VNET thing. Having more or less achieved those goals, perhaps
> the time has come to move on. Having said that, and given that the current
> VIMAGE resource allocation model is far from being optimal (a lot of memory
> sits reserved but 99% unused, and cannot be reclaimed later on vnet
> teardown), perhaps it's time that we reconsider using unified UMA pools.
I think there is a misunderstanding here; it can be reclaimed by the
time we have the teardown properly sorted out and it will immediately
help normal non-VIMAGE systems under memory pressure as well.
The problem is that, at least for TCP (and UDP in one special case as
I found after lots of testing), we are no there yet.
After that, when it comes to resource usage, I am still wondering how
trasz' resource limits will plug into that. By the time we can see
those coming together we should be able to decide whether to go left
or right.
/bz
--
Bjoern A. Zeeb Welcome a new stage of life.
<ks> Going to jail sucks -- <bz> All my daemons like it!
http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/jails.html
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20101117131438.I24596>