Date: Sat, 23 Mar 2002 19:49:04 -0500 (EST) From: Robert Watson <rwatson@freebsd.org> To: "David O'Brien" <obrien@freebsd.org> Cc: Peter Wemm <peter@wemm.org>, Murray Stokely <murray@freebsd.org>, re@freebsd.org, Perforce Change Reviews <perforce@freebsd.org> Subject: Re: PERFORCE change 8258 for review Message-ID: <Pine.NEB.3.96L.1020323193906.47668P-100000@fledge.watson.org> In-Reply-To: <20020323154817.B18453@dragon.nuxi.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, 23 Mar 2002, David O'Brien wrote: > On Sat, Mar 23, 2002 at 03:09:35PM -0800, Peter Wemm wrote: > > > > How about a compromise? > > Your patch is good to me. But it sounds like Robert doesn't like the > extra malloc debugging. From what he wrote, I think it should be turned > off in -CURRENT as it sounds like people don't believe it is serving a > useful purpose. For those interested, my arguments for turning it off were: - It causes third party applications to break due to bugs in those applications, and that will generate spurious bug reports from the DP. For example, I recently turned the flags on on a production server and two applications began core-dumping on start. We probably want to strive for application compatibility in the DP to avoid this sort of failure. - It causes a performance hit that can be difficult to quantify, but can be real. I got hit by it on a fairly loaded apache using perl CGI's regularly. It appears that applications which like to be careful to free all memory on exit generate much more load than applications which just exit. This in particular affects languages using our C library to support garbage collection. phk also pointed at Netscape as a 'worst case scenario'. In a more general sense: - These options are useful for debugging base system utilities, but few if any such easy-to-find bugs still exist in FreeBSD due to running with this enabled. This is an argument for enabling in a development branch, or at least intermittently enabling on the dev branch (on for a month or two prior to release perhaps), but possibly less useful for things people want to use. Many of the same arguments relating to turning off kernel debugging features apply. There's also an inevitable trade-off: we plan to print "don't benchmark me" or something to that extent on the 5.0DP1 cd's, noting the debugging features, but inevitably people will get a first impression that will last. Making the system slow with little problem reporting benefit (and possibly lots of spurious reports) isn't the right tradeoff. Robert N M Watson FreeBSD Core Team, TrustedBSD Project robert@fledge.watson.org NAI Labs, Safeport Network Services To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe p4-releng" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.NEB.3.96L.1020323193906.47668P-100000>