Solved buildworld and kernel scheduler questions

wolffnx

wolffnx

Hi , first of all I talk in terms of speed for a desktop box, not for server

I buildword a couple of times for learning, but my question is
what is the advantage of buildworld versus build a custom kernel(including src.conf)


and my second question is about the kernel scheluder, tunning the sysctl parameters could improve speed for example,applications starts faster?
(sounds dumb) but...could be
 
wolffnx said:
I buildword a couple of times for learning, but my question is
what is the advantage of buildworld versus build a custom kernel(including src.conf)
Click to expand...
In general, you should build the World before building your custom kernel for everything to be in sync. But there is no need to build the World if you build your kernels repeatedly with the same source.
 
Argentum said:
In general, you should build the World before building your custom kernel for everything to be in sync.But there is no need to build the World if you build your kernels repeatedly with the same source.
Click to expand...
so, there is not a good reason to buildword for who search to improve performance

and yes, for the machines I used for desktops only compile a custom kernel when upgrade in releases or make a fresh install
 
wolffnx said:
and yes, for the machines I used for desktops only compile a custom kernel when upgrade in releases or make a fresh install
Click to expand...
It is a good practice to build the World with new source code version before building a kernel. Sometimes it may work without that, but sometimes the kernel depends on a new compiler. So, better, after upgrading the source to a new version, it is a good practice to build the World before your first new kernel.
 
wolffnx said:
what is the advantage of buildworld versus build a custom kernel(including src.conf)
Click to expand...
There's no advantage one over the other, i.e. there's no sense of comparing one to the other.
Yes, in theory you can toggle more aggressive optimizations and leave out some things during compilations. Would you really benefit from it ? I doubt it, but you could try and compare.

FreeBSD comes with some default settings you could tune to fit your needs better. It really depends on what you do with the machine. Chances are you don't need to touch anything.
 
It only makes sense to buildworld with a heavily modified src.conf if you're building for a small footprint, i.e. for embedded or small systems. Then you can remove a lot of unused options and features, slimming down the footprint of the base OS. It has little to no effect on performance.
 
SirDice said:
It only makes sense to buildworld with a heavily modified src.conf if you're building for a small footprint, i.e. for embedded or small systems. Then you can remove a lot of unused options and features, slimming down the footprint of the base OS. It has little to no effect on performance.
Click to expand...
I notice that diference, maybe some long years ago (talking about Linux,in redhat 9,debian,etc) compiling a custom the kernel has a notable performance, but in FreeBSD not so much , only notice that has a little speedup on boot,but nothing more
 
wolffnx said:
I notice that diference, maybe some long years ago (talking about Linux,in redhat 9,debian,etc) compiling a custom the kernel has a notable performance, but in FreeBSD not so much , only notice that has a little speedup on boot,but nothing more
Click to expand...
That's because both the kernel and world are already compiled with the most optimal compiler options. The developers already figured those out.
 
wolffnx said:
I notice that diference, maybe some long years ago (talking about Linux,in redhat 9,debian,etc) compiling a custom the kernel has a notable performance, but in FreeBSD not so much , only notice that has a little speedup on boot,but nothing more
Click to expand...
If you’re interested in tuning your FreeBSD installation for performance, the tuning(7) manual page is a good start.

However – Before you start to fiddle with the buttons, ask yourself what you want to achieve exactly.
Do you have a specific performance problem? If so, what is it exactly? Only then you should specifically look for a solution to that problem.
If you just start turning random knobs because the description sounds like it could improve something, chances are you’re making things worse.

And if you don’t have a performance problem, the simple advice is: Don’t touch the knobs. ;)
 
olli@ said:
If you’re interested in tuning your FreeBSD installation for performance, the tuning(7) manual page is a good start.

However – Before you start to fiddle with the buttons, ask yourself what you want to achieve exactly.
Do you have a specific performance problem? If so, what is it exactly? Only then you should specifically look for a solution to that problem.
If you just start turning random knobs because the description sounds like it could improve something, chances are you’re making things worse.

And if you don’t have a performance problem, the simple advice is: Don’t touch the knobs. ;)
Click to expand...

If you just start turning random knobs because the description sounds like it could improve something, chances are you’re making things worse.

Exactly , is just my obsesion to get the maximum performance and improve, but I dont have any performance problem
at contraire, all my boxes run perfectly (desktops and servers)

And if you don’t have a performance problem, the simple advice is: Don’t touch the knobs. ;)

you gave me a dejavu, when I start to touch everything(when I start using fbsd) and cause more slowness and something broke things..so I follow your advice
 
Over in Linux-land there's some unpleasantness around kernel headers changing to the point where some distros package the kernel headers separately. That's one reason why you would do the equivalent of a "build world" on Linux, the kernel headers changed out from under you. I take it kernel header changes are unlikely to be a problem in Freebsd?
 
Jose said:
I take it kernel header changes are unlikely to be a problem in Freebsd?
Click to expand...
World and kernel should always match up. When you start mix and matching kernel versions with userland versions then you could potentially fall in the same trap. Which is why this sort of set up isn't supported, kernel and world should always match up and be the same version.
 
wolffnx said:
Hi , first of all I talk in terms of speed for a desktop box, not for server
and my second question is about the kernel scheluder, tunning the sysctl parameters could improve speed e.g., applications starts faster
Click to expand...
No, apps do not start faster, but I have set these knobs on my laptop to change FreeBSD's configuration from throughput (server) to interactivity (desktop) (filter of those knobs more or less related to your question):
In loader.conf(5)
Code: 
kern.consmsgbuf_size="65536"    # (8192) [byte] console's circular scroll buffer
kern.hz="2000"                  # (1000) 2000 for better interactivity (laptop/desktop)
kern.ipc.shmseg="1024"          # (128) desktop workload optimization
kern.ipc.shmmni="1024"          # (192)         - " -
kern.maxusers="547"             # a prime aprox. 2 * $(wc -l /etc/passwd); use primes(1)

net.inet.tcp.soreceive_stream="1" # TODO document why this was set

vfs.zfs.mdcomp_disable="1"      # speed up metadata access on SSD: don't compress metadata
In
Code: 
# $FreeBSD: releng/12.2/sbin/sysctl/sysctl.conf 337624 2018-08-11 13:28:03Z brd $
#
#  This file is read when going to multi-user and its contents piped thru
#  ``sysctl'' to adjust kernel values.  ``man 5 sysctl.conf'' for details.
#
#  # (default) [unit] description/notes; unit ommited for booleans & numbers.
#  Please keep the entries sorted, to avoid duplicates (last entry rules).
#
# $Id: sysctl.conf,v 1.5 2021/02/27 17:58:34 root Exp root $
#-----------------------------------------------------------------------------------------
# dev.pcm.0.%desc: Intel Broadwell (HDMI/DP 8ch)        (on-chip)
# dev.pcm.1.%desc: Realtek ALC292 (Analog 2.0+HP/2.0)   (sound chip on mainboard)
# dev.pcm.2.%desc: Realtek ALC292 (Internal Analog Mic)
# see hw.snd.default_unit=1
dev.pcm.0.bitperfect=1                  # (0) enhanced sound quality
dev.pcm.1.bitperfect=1
dev.pcm.2.bitperfect=1
dev.pcm.0.play.vchanmode=2              # (?) [0=fixed|1=passthru|2=adaptive]
dev.pcm.1.play.vchanmode=2              # automagically add virtual private channels (VPC)
dev.pcm.1.rec.vchanmode=2               # (per-application audio channel to control volume)
dev.pcm.0.play.vchans=4                 # (1) more virtual (per-application) sound channels
dev.pcm.1.play.vchans=4                 # (1) more virtual (per-application) sound channels
#dev.pcm.2.play.vchans=1                # N/A
#dev.pcm.0.rec.vchans=1                 # N/A
dev.pcm.1.rec.vchans=4                  # (1) more virtual (per-application) sound channels
dev.pcm.2.rec.vchans=4                  # (1) more virtual (per-application) sound channels

#hw.ibrs_disable=0                      # (1) set to 0 by cpupdate(8) if the CPU supports it
hw.intrbalance=1                        # (0) IRQ balance on multi core CPUs
                                        # (only useful for high-load systems?)
hw.snd.feeder_eq_exact_rate=1           # (0) force exact rate validation
hw.snd.feeder_rate_quality=3            # (0) 0...4 (low...high)
hw.snd.latency=3                        # (?) [0:low...10=high] sound bufferring latency
                                        # NOTE low values increase IRQ load
hw.snd.timeout=1                        # (5) [s]
hw.snd.verbose=1                        # (0) 0...? (can be > 1 for increased verbosity)
#hw.snd.vpc_reset=0                     # (0) reset volume on all channels
hw.snd.vpc_autoreset=0                  # (1) 0: keep settings
hw.snd.vpc_mixer_bypass=0               # (0?)

kern.elf32.aslr.enable=1                # ASLR: Adress Space Layout Randomisation
kern.elf32.aslr.pie_enable=1            # for enhanced security
kern.elf64.aslr.enable=1                # (minimises attack surface)
kern.elf64.aslr.pie_enable=1
kern.evdev.rcpt_mask=6                  # see pkg message x11-servers/xorg-server
#kern.ipc.shm_use_phys=1                # (1?)
kern.nodump_coredump=1                  # set NODUMP flag on core dumps (don't backup)
                                        # not related to desktop, but I show it anyway:
kern.random.fortuna.minpoolsize=512     # (64)? increased pool size for random number generator
kern.randompid=1                        # randomize PID to minimise attack surface
# in loader.conf: kern.hz=2000 (1000)
# sysctl kern.clockrate (default): hz = 1000, tick = 1000 �s, profhz = 8128, stathz = 127
# sysctl kern.clockrate (desktop): hz = 2000, tick =  500 �s,           - " -
# naive attempt for better interactivity: double or halve the respective values
# NOTE this also slightly increases the load induced by the scheduler & thus energy consuption
kern.sched.always_steal=1               # (0) run the stealer from idle thread
kern.sched.affinity=2                   # (1 ms) [1/hz] i.e. if hz=2000 -> default aff.=2
kern.sched.preempt_thresh=224           # (80) max. (lowest) priority for preemption
                                # increase to ~200 for better responsiveness under high CPU load
kern.sched.slice=6                      # (12) [1/stathz] -> default quantum = 94 ms
kern.timecounter.alloweddeviation=2     # (5) [%] allowed deviation

#security.bsd.see_other_uids=1          # (1) replaced by security.mac.seeotheruids.*
security.bsd.see_jail_proc=0            # (1) allow unprivileged users to see jail procs
security.bsd.unprivileged_idprio=1      # (0) allow unprivileged users to set idle priority
security.mac.seeotheruids.specificgid=20 # (0?) id staff=20
security.mac.seeotheruids.specificgid_enabled=1 # (0) rc.conf:kld_load=mac_seeotheruids

vfs.read_max=128                        # (64) Cluster read-ahead max block count
# Enable user mounts e.g. UFS on external media (via hald(8))
vfs.usermount=1                         # restricted to group 'operator' in devfs.rules(5)
vfs.zfs.arc_meta_strategy=1             # [0=only metadata|1=balance data & metadata] ARC metadata reclamation
vfs.zfs.cache_flush_disable=1           # (0) Laptop has builtin UPS
vfs.zfs.min_auto_ashift=12              # (9) Force 1 MB sector boundaries?
vfs.zfs.vdev.bio_flush_disable=1        # (0) Laptop has builtin UPS

# not related to desktop:
vm.overcommit=6         # bit 0: enforce vm.swap_reserved <= vm.swap_total (!only with VERY large swap!)
                        # bit 1: enforce RLIMIT_SWAP
                        # bit 2: allow most phys. mem. as allocatable
If anyone considers any of my "tuning" wrong or dangerous, please comment.
 
I really wish sysctl tuning wasn't so ad-hoc and undefined. Your setup highlights a problem with it. Nice setup nonetheless.
 
Beastie7 said:
I really wish sysctl tuning wasn't so ad-hoc and undefined. Your setup highlights a problem with it.
Click to expand...
??? What is ad-hoc & undefined in this context? Can you elaborate? Which problem do you mean? What I see is the problem that some knobs are not independant, and when one changes, the dependants are not updated accordingly. If that happens, i's clearly a programming error. When you know of any of such sysctl knobs, file in a bug report.
Beastie7 said:
Nice setup nonetheless.
Click to expand...
Thx
 
There's no way to dynamically interact with and retrieve context about interfaces in the MIB. The whole dot naming convention assumes you know the context of what you're tuning, but it's very undefined in its purpose. sysctlinfo helps, but it's still sort-of limited, IMO.
 
Hm. Took me a couple of minutes to realise that MIB in this context is not the SNMP MIB...
Beastie7 said:
There's no way to dynamically interact with and retrieve context about interfaces in the MIB.
Click to expand...
There is sysutils/sysctlinfo-kmod & sysutils/sysctlbyname-improved-kmod. Several ports provide some language bindings, do you mean things like that should be provided by the sysctl(8) utility?
Beastie7 said:
The whole dot naming convention assumes you know the context of what you're tuning, but it's very undefined in its purpose.
Click to expand...
I do not see this as a flaw. The sysctl knobs are kernel & module config vars exposed to userland. Naturally you should have some basic knowledge when you touch these. Not that I claim to posess this for all that I changed above, but I did at least a little bit of research in most cases. S/t I even RTSL when I was suspicious that I could cause any harm. One of the big advantages of an open source OS.
Beastie7 said:
sysctlinfo helps, but it's still sort-of limited, IMO.
Click to expand...
You can help to improve it, e.g. file in a bug report or contact the author directly. I used the prefix "[wishlist]" in bug reports for that purpose. If you have the skills to do so, file in a patch, or for kernel & base related stuff, use the Phabricator's review facility.
 
FMLU the most relevant points are kern.sched.preempt_thresh and to lower the scheduler's timeslice quantum via kern.sched.slice. Maybe I wouldn't even notice any difference with kern.hz=1000. IIRC there was some argument to set it higher, but frankly I don't remember & I forgot to document it... all I wrote was the goal, not why this setting achieves it ;)
 
Argentum said:
I wonder, how high you can go these days with HZ and does it provide any benefit?
Click to expand...
Thx for reminding me not to blindly set knobs where I have no clue what I'm doing ;) I did some quick research:
Benefits to set kern.hz > 1000:
  1. The timer's resolution is higher => more accurate timing e.g. for multimedia
  2. If you set IRQ polling(4) requires setting kern.hz >= 1000. IRQ polling is advantageous, not only for the typical desktop workload (see manpage).
    This reminds me to fgrep -ri polling /usr/src to check if more devices support it. I'm pretty sure that the manpage is outdated.
 
You must log in or register to reply here.
Back
Top