Should i tune compilation of freebsd kernel , or use sysctl.

For once , and exception my Linux config explained. I want to do the same for FreeBSD. Please advice,

Code:
1. Desktop Responsiveness & Gaming
      [*]CONFIG_SCHED_CLASS_EXT=y (sched_ext):
            This is the "game changer." It allows you to load BPF-based schedulers from userspace  
             (such as        scx_rustland or scx_lavd). These are often much better at prioritizing interactive 
             tasks (your desktop/game) over heavy background task (compiling).
      [*]CONFIG_SCHED_AUTOGROUP=y:
            This groups tasks per terminal/session. If you are compiling with make -j in one terminal,
             this ensures the entire compile session is treated as a single "group,"
             preventing your desktop environment in another group from being completely "suffocated."
      [*]CONFIG_CPU_FREQ_GOV_SCHEDUTIL=y:
              The scheduler provides direct feedback to the CPU regarding the required speed.
              This is more efficient and faster than the old 'ondemand' governor, which helps with erratic 
               framerates in games.

2. Parallel Compiling (CPU Load)
      [*]CONFIG_FAIR_GROUP_SCHED=y & CONFIG_CGROUP_SCHED=y:
            These ensure that CPU time is distributed fairly. Even if you are using 32 threads for your compile,
            these options ensure the rest of your system still receives CPU cycles.
      [*]CONFIG_SCHED_MC=y & CONFIG_SCHED_SMT=y:
            Crucial for modern CPUs. The scheduler understands the hierarchy of your cores and threads 
            (SMT/Hyperthreading) allowing compilation to be distributed across the physical hardware more efficiently.

3. Disk Load (I/O Schedulers) During compilation, you are writing thousands of small files.
      [*]CONFIG_IOSCHED_BFQ=y:
            This is the best choice for your scenario. BFQ (Budget Fair Queuing) is designed to keep the desktop 
            responsive while heavy I/O is occurring (such as compiling on an SSD or HDD).
            It prevents a single process from hogging the entire disk bandwidth.

4. Gaming & NVIDIA
      [*]CONFIG_DRM_SCHED=m:
            The Direct Rendering Manager scheduler handles the management of GPU tasks. Although the NVIDIA driver 
            largely does its own management (proprietary), this is necessary for the general graphics stack.
      [*]CONFIG_SCHED_CORE=y:
            This can help with security (against SMT attacks), but in some cases, it incurs a very small performance hit.
            For pure gaming, this is sometimes disabled, but for a secure system, it is fine.

Summary advice for your setup:
              Your kernel is excellently configured for a "workstation/gaming" hybrid. Thanks to sched_ext, 
               you have the ability to use very modern schedulers specifically designed to keep games 
               running smoothly while you compile in the background.
Tip: Use the BFQ scheduler for your disk and look into scx_loader to activate a BPF scheduler (such as scx_rustland) 
for the best experience during compilation.
 
My opinion only:
Use sysctls as much as possible and GENERIC kernel.
Once you start building kernel and userland from source you pretty much lose the ability to do freebsd-update.

As for what FreeBSD sysctls/config options map to those Linux options, I have no idea. Maybe ask ChatGPT?
 
Answer from wise google ai :),

/etc/rc.conf
Code:
powerd_flags="-a hiadaptive"

sysctl.conf:
Code:
# Increase interactive responsiveness
kern.sched.preempt_thresh=85
# Shorten time slices for faster task switching
kern.sched.slice=1
# Improve general desktop I/O
vfs.read_max=64
# 4. Snellere verwerking van directory-informatie (handig bij compileren)
vfs.vmiodirenable=1

Kernel,
Code:
options         PREEMPTION          # Allows threads to be interrupted
options         FULL_PREEMPTION     # More aggressive (lower latency)
# options         ADAPTIVE_MUTEXES    # Faster locking for high core counts ; obsolete
 
Workload :
Always having fast responsive desktop. Windows & mouse.

Or 1, i compile hundreds of packages using poudriere with load on cpu / memory /disk
Or 2, i play games , nvidia card , want fast

So in fact a mix of 3 different requirements

I don't run "Servers with load" , "& I don't need high security as i am behind my router".
 
Workload :
Always having fast responsive desktop. Windows & mouse.

Or 1, i compile hundreds of packages using poudriere with load on cpu / memory /disk
Or 2, i play games , nvidia card , want fast

So in fact a mix of 3 different requirements

I don't run "Servers with load" , "& I don't need high security as i am behind my router".

You list 2 workloads and say "3".

Anyway, gaming with no background load is trivial. Since there's no competition it doesn't matter how smart you schedule.

As for desktop with compilation in the background, do you observe actual problems (other than when you run out of RAM)?
 
It's poudriere tuning,
First i do many packages in parallel , few threads.
Then i do 2 packages in parallel , many threads. eg mongo / chromium / etc...
I check swap usage , have 32GB memory , 5GB of swap ok.
 
Are you doing the poudiere builds on the same machine at the same time you are trying to browse FreeBSD forums?

If so that is a different workload from "I'm just building on that machine while I browse on a different one"
Builds are typically memory intensive especially when doing things in parallel, GUI stuff can take memory but needs more responsiveness (I hit a key I need to see it appear within 10ms) which often implies context switching.
Doing both at the same time, you have to accept builds take longer because you may be constantly task switching to provider user responsiveness.
 
/etc/rc.conf
powerd_flags="-a hiadaptive"
dev.hwpstate_intel.0.epp="0" is cooler :cool:
3. Disk Load (I/O Schedulers) During compilation, you are writing thousands of small files. [*]CONFIG_IOSCHED_BFQ=y: This is the best choice for your scenario.
I'd have no scheduler with NVMe (general software scheduling likely slower than hardware-specific NVMe scheduling)
1. Desktop Responsiveness & Gaming [*]CONFIG_SCHED_CLASS_EXT=y (sched_ext): This is the "game changer." It allows you to load BPF-based schedulers from userspace (such as scx_rustland or scx_lavd).
I prefer traditional schedulers; an article implied sched_ext is useful for HT/SMT, which (imo) can't provide as-good a desktop experience vs no HT/SMT (sounds like sched_ext was designed for cloud/VM or dozens-of-cores-SMT newer hardware with higher OTB latency, and I'm sure software HT/SMT scheduling clashes or doesn't work with with BIOS settings like pair/round-robin/fixed and AP threads causing stuff like XHCI being single-threaded driver-side but IRQ shuffled quietly by BIOS and/or USB ending up on a logical)

AI trying to call something like that a game changer is amusing :p
 
It's poudriere tuning,
First i do many packages in parallel , few threads.
Then i do 2 packages in parallel , many threads. eg mongo / chromium / etc...
I check swap usage , have 32GB memory , 5GB of swap ok.

Again, the question is whether you run your desktop at the same time and if so whether you notice issues.
 
Repeat what i said , maybe using wrong wording.
- First goal , running a desktop which is smooth and fast watever i do , mouse quick. Windows update quick

- Now second goal, within this desktop i have in life two settings,
---------------- Or i play games and then i want high frame rating.
-----------------Or i compile poudriere , and listing to music on youtube , do some simple web browsing. Freebsd... etc.
 
Repeat what i said , maybe using wrong wording.
- First goal , running a desktop which is smooth and fast watever i do , mouse quick. Windows update quick

- Now second goal, within this desktop i have in life two settings,
---------------- Or i play games and then i want high frame rating.
-----------------Or i compile poudriere , and listing to music on youtube , do some simple web browsing. Freebsd... etc.

OK, so desktop and building at the same time.

Do you currently observe problems doing that? Does youtube stutter or something?
 
Or 1, i compile hundreds of packages using poudriere with load on cpu / memory /disk
I use ZFS "sync=disabled". zfsprops(). In case of certain collaborating distributed systems, you cannot use this, because usually the sync is used for storing commited external operations, but for a local system, you loose 5s of transactions (or the value set in "zfs_txg_timeout") in worst case scenario. You will never corrupt the local file system. It is also nicer for the wearing of SSD, because more ops are batched.
 
If I were to build something with a very specific purpose - like a bridge with filtering and traffic shaping - then I would configure the kernel.

If I were to build a desktop I would use the config files.

/grandpa
 
I use ZFS "sync=disabled". zfsprops(). In case of certain collaborating distributed systems, you cannot use this, because usually the sync is used for storing commited external operations, but for a local system, you loose 5s of transactions (or the value set in "zfs_txg_timeout") in worst case scenario. You will never corrupt the local file system. It is also nicer for the wearing of SSD, because more ops are batched.
Eg for poudriere builds & datasets ? No ZIL
 
I'd have no scheduler with NVMe (general software scheduling likely slower than hardware-specific NVMe scheduling)
There is options CAM_IOSCHED_DYNAMIC non-default build time option (kernel configuration), but maybe it's not the OP wants.

And as this is kernel configuration, enabling it requires custom kernel.

From my memo in my kernel configuration file:
Code:
# Adaptive disk write throttling to avoid read performance degradation.
# BIO_ORDERED between read and write should stop working by this.
# Introduced as CAM_IOSCHED_NETFLIX at r298002 and renamed at r302163
# (IFDEFs in codes) and r302204 (sys/conf).
 
Back
Top