Date: Fri, 17 Jun 2005 11:09:54 +0100 (BST) From: Robert Watson <rwatson@FreeBSD.org> To: "Stephane E. Potvin" <sepotvin@videotron.ca> Cc: alc@FreeBSD.org, freebsd-current@FreeBSD.org Subject: Re: Reboot while booting with new per-CPU allocator Message-ID: <20050617110902.C56734@fledge.watson.org> In-Reply-To: <20050616184127.L27625@fledge.watson.org> References: <42B18536.3080200@videotron.ca> <20050616151502.X27625@fledge.watson.org> <42B192D2.7000505@videotron.ca> <20050616181820.E27625@fledge.watson.org> <42B1B784.8010405@videotron.ca> <20050616184127.L27625@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 16 Jun 2005, Robert Watson wrote: >> Great :) It did the trick. The laptop is happily booting with the new >> allocator now. Thanks a lot to you and Alan Cox. > > Looks like what basically happened is this these kern_malloc.c changes > increase the memory burden on UMA as statistics structures for malloc > types now get allocated from UMA. It looks like, from your dmesg, you > have a fair number of modules loaded, so the storage for the statistics > comes out of the early UMA page pool, whereas before it came out of BSS. > We'll see if further tuning is required or not with large numbers of > modules. The thing that surprised me, though, is the unclean failure > mode. The other report saw a clean panic which presumably made > debugging it much easier... Interestingly, there's been a bunch of reports of this in the past few days, and there weren't immediately after the malloc commit. I wonder if some other recent change has increased the amount of UMA memory allocated early in the boot, increasing the level of reports... Robert N M Watson
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20050617110902.C56734>