Re: Setting a default value for OPT_INIT_ALL (stable=zero, current=pattern)

Alexander Leidinger <[email protected]> Wed, 15 Jan 2025 15:01:04 +0100
Newsgroups	gmane.os.freebsd.architechture
Organization	No organization, this is a private message.
Message-ID	<[email protected]>
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 [email protected]: PGP 0x8F31830F9F2772BF
http://www.FreeBSD.org    [email protected]  : PGP 0x8F31830F9F2772BF
signature.asc (application/pgp-signature, 833 B)