Re: Freebsd 14.3 wired memory custom or generic kernel

i see, majority of all that 120mb wired memory is triangle of virtual 
memory, buffer and cache as it seems to be.

what bothered me was even with generic kernel wired memory was 120mb, 
and even with a 15MB sized kernel , wired memory was 120mb.

thank you for your guidance and help :)

========================================================================

if its possible, could you also comment on "Regarding the fact that 
kldstat(8) and du(1) on kernel file report different sizes"

1> 
https://forums.freebsd.org/threads/freebsd-14-3-custom-kernel-wired-memory.99057/post-715476
2> i got this from google gemini, regarding why size is initialized to 0 
and where `size` itself is set.

The size field of a linker_file structure is not set directly by 
kobj_create(). kobj_create() is part of the kernel object (kobj) system, 
which is used for creating polymorphic objects within the kernel, but it 
doesn't handle the core loading and sizing of kernel modules.

The size of a linker_file is set by the kernel linker when it loads the 
module from disk into memory.

The Kernel Linking Process

     kldload(8): When you run kldload mymodule.ko, the userland utility 
sends a request to the kernel to load a module.

     kld_load(): The kernel receives this request and calls the 
kld_load() function in /usr/src/sys/kern/kern_linker.c.

     File Reading and Mapping: kld_load() is responsible for opening the 
.ko file, reading its contents, and allocating memory for it. It's 
during this process that the size is determined. The linker reads the 
ELF header of the module file, which contains information about the size 
of the code, data, and symbol sections.

     linker_load_module(): The core work is done by 
linker_load_module(), which is called by kld_load(). This function 
parses the ELF file format, allocates the necessary memory, and then 
copies the sections (text, data, BSS) from the file into that memory. 
The total size of all these sections and the relocation information is 
calculated, and this final value is used to set the size field of the 
linker_file structure.

     Relocation and Initialization: After the module is loaded and its 
size is set, the linker performs relocations (fixing up addresses) and 
then calls the module's initialization function (MOD_LOAD event).

kobj_create()'s role is different. A kernel module might use 
kobj_create() to create objects for its internal use, but this happens 
after the module itself has been loaded and its overall size has been 
determined and recorded by the kernel linker. The size parameter in 
kobj_create() refers to the size of the specific object being created, 
not the size of the entire kernel module file.

thank you again
-kun

On 9/8/25 2:07 AM, Eugene Grosbein wrote:
> 08.09.2025 5:21, kunn wrote:
> 
>> command: "vmstat -z | sed 's/:/,/' | awk -F, '{printf "%10s %s\n", $2*$4/1024/1024, $1}' | sort -k1,1 -rn | head"
>> output:
>> 23.2852 vm pgcache
>> 18.9492 vm pgcache
>> 9.91821e-05 fakepg
>> 6.10352e-05 pcpu-16
>> 3.05176e-05 udp_inpcb ports
>> 2.20312 kstack_cache
>> 1.98438 mbuf_cluster
>> 1.82812 malloc-4096
>> 1 mbuf_jumbo_page
>> 0.907349 malloc-128
> 
> Well, it explains most part of wired memory usage, in megabytes.
> First two lines show 42.2MB of virtual memory page cache in total.
> 
> kstack_cache + mbuf_cluster + malloc* + mbuf_jumbo_page
> sum to about 8MB extra wired memory to about 60MB including above 42.2MB.
> 
> Add to this a number shown with "kldstat -h" multipled by two,
> that's amount of wired memory reserved at boot time for kernel code itself and its
> internal working set needed to start the rest of the system and thereafter.
> 
> Some more kernel dynamic memory allocated using malloc(9) is shown with "vmstat -m".
>