Re: Weird performances: -CURRENT vs 5.2.1

From: Craig Reyenga <craig_at_bluemidnight.ca>
Date: Thu, 19 Aug 2004 15:44:59 -0400
----- Original Message -----
From: "sam" <sam.wun_at_tech-21.com.hk>
To: "Marc Fonvieille" <blackend_at_freebsd.org>
Cc: "Kris Kennaway" <kris_at_obsecurity.org>; <freebsd-current_at_freebsd.org>;
"Mike Tancsa" <mike_at_sentex.net>
Sent: Thursday, August 19, 2004 3:31 AM
Subject: Re: Weird performances: -CURRENT vs 5.2.1


> Marc Fonvieille wrote:
>
> >On Wed, Aug 18, 2004 at 05:05:13PM -0400, Mike Tancsa wrote:
> >
> >
> >>Hi,
> >>        As someone who is also going to start testing the waters with
> >>RELENG_5 on some non critical production servers (e.g. one of n spam and
av
> >>scanning machines), I take it you mean,
> >>
> >>
> >>NOTE TO PEOPLE WHO THINK THAT FreeBSD 5.x IS SLOW:
> >>        FreeBSD 5.x has many debugging features turned on, in
> >>        both the kernel and userland.  These features attempt to detect
> >>        incorrect use of system primitives, and encourage loud failure
> >>        through extra sanity checking and fail stop semantics.  They
> >>        also substantially impact system performance.  If you want to
> >>        do performance measurement, benchmarking, and optimization,
> >>        you'll want to turn them off.  This includes various WITNESS-
> >>        related kernel options, INVARIANTS, malloc debugging flags
> >>        in userland, and various verbose features in the kernel.  Many
> >>        developers choose to disable these features on build machines
> >>        to maximize performance.
> >>
> >>
> >>Are there more details somewhere as to what exactly to turn off and
tweak ?
> >>
> >>
> >>
> >
> >It's not really documented.  To sum up, you have to remove these lines
> >from your kernel configuration file:
> >
> >makeoptions     DEBUG=-g                # Build kernel with gdb(1) debug
symbols
> >
> ># Debugging for use in -current
> >options         KDB                     # Enable kernel debugger support.
> >options         DDB                     # Support DDB.
> >options         GDB                     # Support remote GDB.
> >options         INVARIANTS              # Enable calls of extra sanity
checking
> >options         INVARIANT_SUPPORT       # Extra sanity checks of internal
struct
> >ures, required by INVARIANTS
> >options         WITNESS                 # Enable checks to detect
deadlocks and cycles
> >options         WITNESS_SKIPSPIN        # Don't run witness on spinlocks
for spe
> >ed
> >
> >In fact INVARIANTS and WITNESS related lines are the more important to
> >maximize performance, the others lines do not really change things.
> >And then do a:
> >
> >ln -s aj /etc/malloc.conf
> >
> >
> This looks like a trick. "aj" is actually not existed in the system.
> You meant created a malloc.conf pointing to a non-exist aj for the
> improvment of the malloc operation?
>
> root_at_fbsd [3:31pm] [...i386/conf]# ls -l /etc/malloc.conf
> lrwxr-xr-x  1 root  wheel  2 Aug 19 15:31 /etc/malloc.conf_at_ -> aj
> root_at_fbsd [3:34pm] [...i386/conf]#
>
> root_at_fbsd [3:34pm] [...i386/conf]# ls -l /etc/aj
> ls: /etc/aj: No such file or directory
> root_at_fbsd [3:34pm] [...i386/conf]#
>

malloc.conf is a symlink read by the kernel to find its configuration. I
haven't looked at the code, but I assume that the kernel uses readlink() and
just finds what chars are in it. This is way less bother than opening a
configuration file and reading it (not to mention a huge amount of error
handling, and security risks). man malloc.conf for more information.

-Craig

> Sam
>
> >This one is important too, by default malloc routines uses AJ flags (be
> >careful with the case) under -CURRENT, even if you don't have any
> >malloc.conf file, look at malloc(3) manual page for more details.
> >
> >Marc
> >
> >
>
> _______________________________________________
> freebsd-current_at_freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscribe_at_freebsd.org"
>
Received on Thu Aug 19 2004 - 17:44:52 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:38:07 UTC