Date: Mon, 11 Feb 2013 08:01:36 -0700 From: Ian Lepore <ian@FreeBSD.org> To: Glen Barber <gjb@FreeBSD.org> Cc: freebsd-current@FreeBSD.org, David Chisnall <theraven@FreeBSD.org>, Steve Kargl <sgk@troutmask.apl.washington.edu> Subject: Re: 7+ days of dogfood Message-ID: <1360594896.4545.81.camel@revolution.hippie.lan> In-Reply-To: <20130211141512.GN1334@glenbarber.us> References: <20130210000723.GA73630@troutmask.apl.washington.edu> <20130211114811.09e56b55@fabiankeil.de> <17E009FB-23FA-4E04-8437-DE81033164DE@FreeBSD.org> <20130211145647.79a01f7e@fabiankeil.de> <20130211141512.GN1334@glenbarber.us>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 2013-02-11 at 09:15 -0500, Glen Barber wrote: > On Mon, Feb 11, 2013 at 02:56:47PM +0100, Fabian Keil wrote: > > > WITHOUT_GCC=yes in src.conf is > > > worthwhile. WITHOUT_GDB=yes is probably also sensible, as the gdb in > > > base is so old that it doesn't understand most of the DWARF that clang > > > uses. We should have lldb ready for import in a few months, but until > > > then using gdb from ports is more sensible if you plan on actually doing > > > any debugging. > > > > So far I didn't consider not building gdb, but I agree that it's > > not too useful when compiling with clang and am already using > > gdb751 for debugging anyway. > > > > My impression was that the base gdb compiles rather quickly > > (compared to more recent versions) and that it thus wouldn't > > matter, but I'll give it a try. > > > > Thanks for the suggestion. > > > > You might also want to try MALLOC_PRODUCTION=1 in make.conf. This took > my buildworld/buildkernel times from 35/15 minutes to 8/5 minutes, > respectively. > > Glen Actually, anyone who is routinely setting MALLOC_PRODUCTION to run -current, please considering trying again without it. One particular sanity check enabled without MALLOC_PRODUCTION was responsible for virtually all of the performance degradation, and the recent import of a new jemalloc reworked that code to eliminate the problem (it was needlessly validating that freshly mmap'd memory was zeroed; now it only does that validation if it internally recycles a block, and I think it never even does that on freebsd). -- Ian
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1360594896.4545.81.camel>