Date: Wed, 17 Nov 2010 07:23:01 +0000 (UTC) From: "Bjoern A. Zeeb" <bzeeb-lists@lists.zabbadoz.net> To: Thierry Herbelot <thierry.herbelot@free.fr> Cc: FreeBSD virtualization mailing list <freebsd-virtualization@freebsd.org> Subject: Re: VIMAGE: Freed UMA keg was not empty Message-ID: <20101117072103.R24596@maildrop.int.zabbadoz.net> In-Reply-To: <201011170729.41894.thierry.herbelot@free.fr> References: <201011170627.28025.thierry.herbelot@free.fr> <20101117055208.S24596@maildrop.int.zabbadoz.net> <201011170729.41894.thierry.herbelot@free.fr>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 17 Nov 2010, Thierry Herbelot wrote: Hi, >> The problem has been present since day 1 and is still present up to >> HEAD. This is about type stability and teardown. So far we are no >> able to actually free TCP (and UDP in SVN) states as they might still >> be accesses after "free". It's a general problem in the network stack >> and has been implemented as a measure to circumvent panics in those >> cases. >> >> I am not sure if that's actually what's biting you wrt to memory or >> if it's something else. Unfortunately boot logs and kernel configs >> don't help much; enable ddb and get show uma and show malloc reports >> after the crash (or watch vmstat -z and vmstat -m) after every 50 jail >> restarts. I might have some patches for a couple of things but cannot >> (yet) help with the additional (duplicate) UMA zones showing up at >> each iteration (for the -z case). > > The context for our problem is that VIMAGE jails are mant to be used "in > production" for automated tests, thus are likely to be multiple on one > physical host, and are likely to be started and stopped according to our > needs. > > We have tried more "classical" virtualization solutions (qemu, kvm, ... , > normal jails with individual FIBs, ...) but only FreeBSD with VIMAGE seems to > be the correct answer. (for other reasons, an i386 version of the kernel must > be used) > > The point of my original email was to simplify the configuration for a test > setup : any machine with the attached configuration file and the above > sequence of commands creating and deleting jails, running in a loop, will > eventually panic. The thing you can do is start the jails persistent and then only garbage collect proceses and network configuration manually and reconfigure/restart things for the next iteration; you might still leak network stack details between runs but if that's not a problem for you the solution might work. Regards, Bjoern -- 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?20101117072103.R24596>