Re: Setting a default value for OPT_INIT_ALL (stable=zero, current=pattern)
- In reply to: Shawn Webb : "Re: Setting a default value for OPT_INIT_ALL (stable=zero, current=pattern)"
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
Date: Wed, 15 Jan 2025 14:01:04 UTC
Am 2025-01-12 19:05, schrieb Shawn Webb: > On Sun, Jan 12, 2025 at 01:06:06PM +0100, Alexander Leidinger wrote: >> I have most of the kernel stuff as modules, so this should all be >> compiled >> with =zero (except the isal and nvidia modules, I have just >> compiled-tested >> the ports I use but not yet run tested with a similar feature for the >> ports >> collection): >> Id Name >> 1 kernel >> 2 opensolaris.ko >> 3 usbhid.ko >> 4 hidbus.ko >> 5 hid.ko >> 6 kbdmux.ko >> 7 coretemp.ko >> 8 hsctrl.ko >> 9 hidmap.ko >> 10 tcphpts.ko >> 11 ahci.ko >> 12 hcons.ko >> 13 if_igb.ko >> 14 iflib.ko >> 15 cryptodev.ko >> 16 cc_chd.ko >> 17 aesni.ko >> 18 tcp_rack.ko >> 19 nvme.ko >> 20 smbios.ko >> 21 efirt.ko >> 22 vkbd.ko >> 23 zfs.ko >> 24 xdr.ko >> 25 cpufreq.ko >> 26 dpms.ko >> 27 hkbd.ko >> 28 umass.ko >> 29 miibus.ko >> 30 geom_eli.ko >> 31 geom_label.ko >> 32 tmpfs.ko >> 33 fdescfs.ko >> 34 if_bridge.ko >> 35 bridgestp.ko >> 36 if_epair.ko >> 37 xhci.ko >> 38 firewire.ko >> 39 if_fwip.ko >> 40 filemon.ko >> 41 sound.ko >> 42 ulpt.ko >> 43 accf_dns.ko >> 44 accf_data.ko >> 45 accf_http.ko >> 46 accf_tls.ko >> 47 cpuctl.ko >> 48 tpm.ko >> 49 ipmi.ko >> 50 linux.ko >> 51 mqueuefs.ko >> 52 linux_common.ko >> 53 linux64.ko >> 54 nullfs.ko >> 55 cuse.ko >> 56 isal.ko >> 57 nvidia-modeset.ko >> 58 nvidia.ko >> 59 hms.ko >> 60 ioat.ko >> 61 snd_uaudio.ko >> 62 pf.ko >> 63 procfs.ko >> 64 pseudofs.ko >> 65 linprocfs.ko >> 66 linsysfs.ko > > I would especially be curious about crypto and platform (like EFIRT) > kernel modules. If you do enable trivial variable auto-init for any of > what you listed, please let me know which ones work. I rebooted the system yesterday, so the stats are just about the last 18h: # sysctl kern.ipc.tls.stats kern.ipc.tls.stats.ocf.retries: 0 kern.ipc.tls.stats.ocf.separate_output: 105 kern.ipc.tls.stats.ocf.inplace: 61464 kern.ipc.tls.stats.ocf.tls13_chacha20_encrypts: 2 kern.ipc.tls.stats.ocf.tls13_chacha20_decrypts: 0 kern.ipc.tls.stats.ocf.tls13_gcm_recrypts: 0 kern.ipc.tls.stats.ocf.tls13_gcm_encrypts: 61484 kern.ipc.tls.stats.ocf.tls13_gcm_decrypts: 56742 kern.ipc.tls.stats.ocf.tls12_chacha20_encrypts: 1 kern.ipc.tls.stats.ocf.tls12_chacha20_decrypts: 0 kern.ipc.tls.stats.ocf.tls12_gcm_recrypts: 0 kern.ipc.tls.stats.ocf.tls12_gcm_encrypts: 82 kern.ipc.tls.stats.ocf.tls12_gcm_decrypts: 48 kern.ipc.tls.stats.ocf.tls11_cbc_encrypts: 0 kern.ipc.tls.stats.ocf.tls11_cbc_decrypts: 0 kern.ipc.tls.stats.ocf.tls10_cbc_encrypts: 0 kern.ipc.tls.stats.destroy_task: 0 kern.ipc.tls.stats.ifnet_disable_ok: 0 kern.ipc.tls.stats.ifnet_disable_failed: 0 kern.ipc.tls.stats.switch_failed: 0 kern.ipc.tls.stats.switch_to_sw: 0 kern.ipc.tls.stats.switch_to_ifnet: 0 kern.ipc.tls.stats.failed_crypto: 0 kern.ipc.tls.stats.corrupted_records: 0 kern.ipc.tls.stats.active: 20 kern.ipc.tls.stats.enable_calls: 4824 kern.ipc.tls.stats.offload_total: 4824 kern.ipc.tls.stats.sw_rx_inqueue: 0 kern.ipc.tls.stats.sw_tx_inqueue: 0 kern.ipc.tls.stats.sw_tx_pending: 0 kern.ipc.tls.stats.threads: 24 This looks to me like crypto works with =zero (or my reading of kern.mk is wrong with OPT_INIT_ALL=zero in src.conf, or kmod.mk needs a similar piece of handling this if it is not picked up from kern.mk in module builds). The above list of modules is the live system. linux, efi (the board is supposed to have it, but switching from bios to EFI fails, the issue may be in front of the keyboard), cuse, firewire, tpm, ioat (if nothing uses it automatically when autoloaded by devd) are not in active use, umass, ulpt, sound not yet tested, nvidia and isal are not recompiled yet. So far I have not seen issues. Is someone out there with access to the SPECint CPU2006 benchmark who can do some tests to drill down what may be the reason for the slow-down of 458.sjeng (first question is: is there a slow-down if the bnechmark is not compiled with =zero and the world and kernel are build with =zero, second question would be to profile and check where the degradation happens)? If the degradation doesn't happen when the benchmark is not compiled with =zero, of if it happens in our code and we can fix it, we could go ahead and give the =zero a try on -current before applying it in -stable. Bye, Alexander. -- http://www.Leidinger.net Alexander@Leidinger.net: PGP 0x8F31830F9F2772BF http://www.FreeBSD.org netchild@FreeBSD.org : PGP 0x8F31830F9F2772BF