Kernel huge vs generic

[Chris Elvidge]

Slackware current - VirtualBox 7.0.14

I normally use the huge kernel with no problems but the other day I
mistakenly downloaded the generic kernel, too, and noticed the
difference in size is only 2Mb. I was originally told the generic kernel
was better for memory consumption. The required initrd.gz unzips to 27Mb.

What is the/Is there a supposed advantage of generic + initrd over huge?

Cheers

[Lew Pitcher]

Post by Chris Elvidge
Slackware current - VirtualBox 7.0.14
I normally use the huge kernel with no problems but the other day I
mistakenly downloaded the generic kernel, too, and noticed the
difference in size is only 2Mb. I was originally told the generic kernel
was better for memory consumption. The required initrd.gz unzips to 27Mb.
What is the/Is there a supposed advantage of generic + initrd over huge?

I believe (and others here will correct me if I am wrong) that the "generic"
kernel + initrd result in less memory used in the finally running system than
the "huge" kernel.

Consider: once booted, the generic kernel will (should?) free any memory
occupied by the initrd image, as it no longer needs the initrd image to run.
The generic kernel only needs initrd because it uses (filesystem backed)
modules to provide the disk controller interfaces. This results in a small
initial load module for the kernel. Once executing, it only loads the hardware
drivers it needs, leaving all the rest alone.

OTOH, the "huge" kernel has all the disk controller drivers built-in to
the loaded module. Even if the kernel doesn't use the disk controller, the
code is still resident in memory.

So, the "huge" kernel results in a running kernel with more resident code
than the "generic" kernel.

Having said all that, I run the "huge" kernel; I can't be bothered with
the additional initrd step if/when I upgrade my kernel, and I have the
memory to support the minor additional overhead of unused drivers.

HTH

[Chris Elvidge]

Post by Lew Pitcher

Post by Chris Elvidge
Slackware current - VirtualBox 7.0.14
I normally use the huge kernel with no problems but the other day I
mistakenly downloaded the generic kernel, too, and noticed the
difference in size is only 2Mb. I was originally told the generic kernel
was better for memory consumption. The required initrd.gz unzips to 27Mb.
What is the/Is there a supposed advantage of generic + initrd over huge?

I believe (and others here will correct me if I am wrong) that the "generic"
kernel + initrd result in less memory used in the finally running system than
the "huge" kernel.
Consider: once booted, the generic kernel will (should?) free any memory
occupied by the initrd image, as it no longer needs the initrd image to run.
The generic kernel only needs initrd because it uses (filesystem backed)
modules to provide the disk controller interfaces. This results in a small
initial load module for the kernel. Once executing, it only loads the hardware
drivers it needs, leaving all the rest alone.
OTOH, the "huge" kernel has all the disk controller drivers built-in to
the loaded module. Even if the kernel doesn't use the disk controller, the
code is still resident in memory.
So, the "huge" kernel results in a running kernel with more resident code
than the "generic" kernel.
Having said all that, I run the "huge" kernel; I can't be bothered with
the additional initrd step if/when I upgrade my kernel, and I have the
memory to support the minor additional overhead of unused drivers.
HTH

Thanks for that explanation. My Slack installation is currently using
891Mb out of 3Gb with the huge 6.8.6 kernel and Xfce 4.18 - so no
problems. I'll look at the differences with the 6.6.27 huge and generic
kernels later.

[Chris Elvidge]

Post by Lew Pitcher

Post by Chris Elvidge
Slackware current - VirtualBox 7.0.14
I normally use the huge kernel with no problems but the other day I
mistakenly downloaded the generic kernel, too, and noticed the
difference in size is only 2Mb. I was originally told the generic kernel
was better for memory consumption. The required initrd.gz unzips to 27Mb.
What is the/Is there a supposed advantage of generic + initrd over huge?

I believe (and others here will correct me if I am wrong) that the "generic"
kernel + initrd result in less memory used in the finally running system than
the "huge" kernel.
Consider: once booted, the generic kernel will (should?) free any memory
occupied by the initrd image, as it no longer needs the initrd image to run.
The generic kernel only needs initrd because it uses (filesystem backed)
modules to provide the disk controller interfaces. This results in a small
initial load module for the kernel. Once executing, it only loads the hardware
drivers it needs, leaving all the rest alone.
OTOH, the "huge" kernel has all the disk controller drivers built-in to
the loaded module. Even if the kernel doesn't use the disk controller, the
code is still resident in memory.
So, the "huge" kernel results in a running kernel with more resident code
than the "generic" kernel.
Having said all that, I run the "huge" kernel; I can't be bothered with
the additional initrd step if/when I upgrade my kernel, and I have the
memory to support the minor additional overhead of unused drivers.
HTH

These are the figures I got:

generic-6.6.27
total used free shared buff/cache available
Mem: 2974 1084 890 7 1172 1889
Swap: 6143 0 6143
Total: 9118 1084 7034

huge-6.6.27
total used free shared buff/cache available
Mem: 2971 1069 1201 7 870 1902
Swap: 6143 0 6143
Total: 9115 1069 7345

huge-6.8.6
total used free shared buff/cache available
Mem: 2971 1082 907 8 1163 1889
Swap: 6143 0 6143
Total: 9115 1082 7051

So no noticeable difference AFAICS.
I brewed 6.8.6 from 6.6.27 .config and 'make olddefconfig'

[Lew Pitcher]

Post by Chris Elvidge

Post by Lew Pitcher

Post by Chris Elvidge
Slackware current - VirtualBox 7.0.14
I normally use the huge kernel with no problems but the other day I
mistakenly downloaded the generic kernel, too, and noticed the
difference in size is only 2Mb. I was originally told the generic kernel
was better for memory consumption. The required initrd.gz unzips to 27Mb.
What is the/Is there a supposed advantage of generic + initrd over huge?

I believe (and others here will correct me if I am wrong) that the "generic"
kernel + initrd result in less memory used in the finally running system than
the "huge" kernel.
Consider: once booted, the generic kernel will (should?) free any memory
occupied by the initrd image, as it no longer needs the initrd image to run.
The generic kernel only needs initrd because it uses (filesystem backed)
modules to provide the disk controller interfaces. This results in a small
initial load module for the kernel. Once executing, it only loads the hardware
drivers it needs, leaving all the rest alone.
OTOH, the "huge" kernel has all the disk controller drivers built-in to
the loaded module. Even if the kernel doesn't use the disk controller, the
code is still resident in memory.
So, the "huge" kernel results in a running kernel with more resident code
than the "generic" kernel.
Having said all that, I run the "huge" kernel; I can't be bothered with
the additional initrd step if/when I upgrade my kernel, and I have the
memory to support the minor additional overhead of unused drivers.
HTH

generic-6.6.27
total used free shared buff/cache available
Mem: 2974 1084 890 7 1172 1889
Swap: 6143 0 6143
Total: 9118 1084 7034
huge-6.6.27
total used free shared buff/cache available
Mem: 2971 1069 1201 7 870 1902
Swap: 6143 0 6143
Total: 9115 1069 7345
huge-6.8.6
total used free shared buff/cache available
Mem: 2971 1082 907 8 1163 1889
Swap: 6143 0 6143
Total: 9115 1082 7051
So no noticeable difference AFAICS.

Glad to hear that. Apparently, the inclusion of disk drivers no longer
makes a significant difference on the end resident size of the kernel.

I'd be interested to know what your dmesg says about the kernel memory
Would you be willing to post the results of
dmesg | grep 'Memory:'
and
dmesg | grep 'Freeing unused kernel memory:'
under all three kernels?

That would tell us directly (rather than by implication) how much memory
each kernel takes.

Post by Chris Elvidge
I brewed 6.8.6 from 6.6.27 .config and 'make olddefconfig'

I used to (back in the 2.x days) brew my own kernel. These days, not
so much. I salute you on conquering the kernel build process. :-)

[Chris Elvidge]

Post by Lew Pitcher
Glad to hear that. Apparently, the inclusion of disk drivers no longer
makes a significant difference on the end resident size of the kernel.
I'd be interested to know what your dmesg says about the kernel memory
Would you be willing to post the results of
dmesg | grep 'Memory:'
and
dmesg | grep 'Freeing unused kernel memory:'
under all three kernels?
That would tell us directly (rather than by implication) how much memory
each kernel takes.

dmsg-memory-generic-6.6.27
[ 0.340626] PM: hibernation: Registered nosave memory: [mem
0x00000000-0x00000fff]
[ 0.340632] PM: hibernation: Registered nosave memory: [mem
0x0009f000-0x0009ffff]
[ 0.340635] PM: hibernation: Registered nosave memory: [mem
0x000a0000-0x000effff]
[ 0.340636] PM: hibernation: Registered nosave memory: [mem
0x000f0000-0x000fffff]
[ 0.362893] Memory: 3029884K/3145272K available (22528K kernel code,
3434K rwdata, 7724K rodata, 3728K init, 4868K bss, 115128K reserved, 0K
cma-reserved)
[ 0.437814] Freeing SMP alternatives memory: 64K
[ 1.171765] Freeing initrd memory: 9420K
[ 6.295892] Freeing unused decrypted memory: 2028K
[ 6.311805] Freeing unused kernel image (initmem) memory: 3728K
[ 6.342365] Freeing unused kernel image (rodata/data gap) memory: 468K

dmsg-memory-huge-6.6.27
[ 0.028558] PM: hibernation: Registered nosave memory: [mem
0x00000000-0x00000fff]
[ 0.028561] PM: hibernation: Registered nosave memory: [mem
0x0009f000-0x0009ffff]
[ 0.028563] PM: hibernation: Registered nosave memory: [mem
0x000a0000-0x000effff]
[ 0.028564] PM: hibernation: Registered nosave memory: [mem
0x000f0000-0x000fffff]
[ 0.052446] Memory: 3035204K/3145272K available (24576K kernel code,
3645K rwdata, 8764K rodata, 4064K init, 3508K bss, 109808K reserved, 0K
cma-reserved)
[ 0.146341] Freeing SMP alternatives memory: 68K
[ 6.019644] Freeing unused decrypted memory: 2028K
[ 6.032489] Freeing unused kernel image (initmem) memory: 4064K
[ 6.075487] Freeing unused kernel image (rodata/data gap) memory: 1476K

dmsg-memory-huge-6.8.6
[ 0.028539] PM: hibernation: Registered nosave memory: [mem
0x00000000-0x00000fff]
[ 0.028543] PM: hibernation: Registered nosave memory: [mem
0x0009f000-0x0009ffff]
[ 0.028544] PM: hibernation: Registered nosave memory: [mem
0x000a0000-0x000effff]
[ 0.028545] PM: hibernation: Registered nosave memory: [mem
0x000f0000-0x000fffff]
[ 0.051606] Memory: 3035204K/3145272K available (24576K kernel code,
3653K rwdata, 8864K rodata, 4092K init, 3404K bss, 109808K reserved, 0K
cma-reserved)
[ 0.153368] Freeing SMP alternatives memory: 68K
[ 5.951739] Freeing unused decrypted memory: 2028K
[ 5.967211] Freeing unused kernel image (initmem) memory: 4092K
[ 5.998271] Freeing unused kernel image (rodata/data gap) memory: 1376K

Looks to me as though it frees everything unused.

[Lew Pitcher]

Post by Chris Elvidge

Post by Lew Pitcher
Glad to hear that. Apparently, the inclusion of disk drivers no longer
makes a significant difference on the end resident size of the kernel.
I'd be interested to know what your dmesg says about the kernel memory
Would you be willing to post the results of
dmesg | grep 'Memory:'
and
dmesg | grep 'Freeing unused kernel memory:'
under all three kernels?
That would tell us directly (rather than by implication) how much memory
each kernel takes.

dmsg-memory-generic-6.6.27
[ 0.340626] PM: hibernation: Registered nosave memory: [mem
0x00000000-0x00000fff]
[ 0.340632] PM: hibernation: Registered nosave memory: [mem
0x0009f000-0x0009ffff]
[ 0.340635] PM: hibernation: Registered nosave memory: [mem
0x000a0000-0x000effff]
[ 0.340636] PM: hibernation: Registered nosave memory: [mem
0x000f0000-0x000fffff]
[ 0.362893] Memory: 3029884K/3145272K available (22528K kernel code,
3434K rwdata, 7724K rodata, 3728K init, 4868K bss, 115128K reserved, 0K
cma-reserved)
[ 0.437814] Freeing SMP alternatives memory: 64K
[ 1.171765] Freeing initrd memory: 9420K
[ 6.295892] Freeing unused decrypted memory: 2028K
[ 6.311805] Freeing unused kernel image (initmem) memory: 3728K
[ 6.342365] Freeing unused kernel image (rodata/data gap) memory: 468K
dmsg-memory-huge-6.6.27
[ 0.028558] PM: hibernation: Registered nosave memory: [mem
0x00000000-0x00000fff]
[ 0.028561] PM: hibernation: Registered nosave memory: [mem
0x0009f000-0x0009ffff]
[ 0.028563] PM: hibernation: Registered nosave memory: [mem
0x000a0000-0x000effff]
[ 0.028564] PM: hibernation: Registered nosave memory: [mem
0x000f0000-0x000fffff]
[ 0.052446] Memory: 3035204K/3145272K available (24576K kernel code,
3645K rwdata, 8764K rodata, 4064K init, 3508K bss, 109808K reserved, 0K
cma-reserved)

So, the 6.6.27 "Huge" kernel loaded an additional
2048K of code,
211K of rwdata,
1040K of rodata, and
336K of init
over the "Generic" kernel. But, it used 1360K less bss and
5320K less "reserved" memory than the "Generic" kernel.

Post by Chris Elvidge
[ 0.146341] Freeing SMP alternatives memory: 68K
[ 6.019644] Freeing unused decrypted memory: 2028K
[ 6.032489] Freeing unused kernel image (initmem) memory: 4064K
[ 6.075487] Freeing unused kernel image (rodata/data gap) memory: 1476K

Both the "Generic" and "Huge" kernels freed 2028K of "decrypted" memory, and
all the init memory that they had allocated. The "Generic" kernel also freed
9420K of memory reserved for the initrd (something that the "Huge" kernel
doesn't have).

The "Generic" kernel loaded less "kernel" (37414K vs the "Huge" 41049K), but
/overall/ loaded more when you consider the size of the initrd (46834K vs the
"Huge" 41049K).

So, the "Huge" kernel has a bit larger resident size, but a smaller loader
footprint than the "Generic" kernel.

Post by Chris Elvidge
dmsg-memory-huge-6.8.6
[ 0.028539] PM: hibernation: Registered nosave memory: [mem
0x00000000-0x00000fff]
[ 0.028543] PM: hibernation: Registered nosave memory: [mem
0x0009f000-0x0009ffff]
[ 0.028544] PM: hibernation: Registered nosave memory: [mem
0x000a0000-0x000effff]
[ 0.028545] PM: hibernation: Registered nosave memory: [mem
0x000f0000-0x000fffff]
[ 0.051606] Memory: 3035204K/3145272K available (24576K kernel code,
3653K rwdata, 8864K rodata, 4092K init, 3404K bss, 109808K reserved, 0K
cma-reserved)
[ 0.153368] Freeing SMP alternatives memory: 68K
[ 5.951739] Freeing unused decrypted memory: 2028K
[ 5.967211] Freeing unused kernel image (initmem) memory: 4092K
[ 5.998271] Freeing unused kernel image (rodata/data gap) memory: 1376K
Looks to me as though it frees everything unused.

This "Huge" kernel seems to be only about 136K bigger than the 6.6.7 "Huge"
kernel (+8K rwdata, +100K rodata, +28K init), but has a smaller bss (by
104K).

[Chris Elvidge]

Post by Lew Pitcher

Post by Chris Elvidge

Post by Lew Pitcher
Glad to hear that. Apparently, the inclusion of disk drivers no longer
makes a significant difference on the end resident size of the kernel.
I'd be interested to know what your dmesg says about the kernel memory
Would you be willing to post the results of
dmesg | grep 'Memory:'
and
dmesg | grep 'Freeing unused kernel memory:'
under all three kernels?
That would tell us directly (rather than by implication) how much memory
each kernel takes.

dmsg-memory-generic-6.6.27
[ 0.340626] PM: hibernation: Registered nosave memory: [mem
0x00000000-0x00000fff]
[ 0.340632] PM: hibernation: Registered nosave memory: [mem
0x0009f000-0x0009ffff]
[ 0.340635] PM: hibernation: Registered nosave memory: [mem
0x000a0000-0x000effff]
[ 0.340636] PM: hibernation: Registered nosave memory: [mem
0x000f0000-0x000fffff]
[ 0.362893] Memory: 3029884K/3145272K available (22528K kernel code,
3434K rwdata, 7724K rodata, 3728K init, 4868K bss, 115128K reserved, 0K
cma-reserved)
[ 0.437814] Freeing SMP alternatives memory: 64K
[ 1.171765] Freeing initrd memory: 9420K
[ 6.295892] Freeing unused decrypted memory: 2028K
[ 6.311805] Freeing unused kernel image (initmem) memory: 3728K
[ 6.342365] Freeing unused kernel image (rodata/data gap) memory: 468K
dmsg-memory-huge-6.6.27
[ 0.028558] PM: hibernation: Registered nosave memory: [mem
0x00000000-0x00000fff]
[ 0.028561] PM: hibernation: Registered nosave memory: [mem
0x0009f000-0x0009ffff]
[ 0.028563] PM: hibernation: Registered nosave memory: [mem
0x000a0000-0x000effff]
[ 0.028564] PM: hibernation: Registered nosave memory: [mem
0x000f0000-0x000fffff]
[ 0.052446] Memory: 3035204K/3145272K available (24576K kernel code,
3645K rwdata, 8764K rodata, 4064K init, 3508K bss, 109808K reserved, 0K
cma-reserved)

So, the 6.6.27 "Huge" kernel loaded an additional
2048K of code,
211K of rwdata,
1040K of rodata, and
336K of init
over the "Generic" kernel. But, it used 1360K less bss and
5320K less "reserved" memory than the "Generic" kernel.

Post by Chris Elvidge
[ 0.146341] Freeing SMP alternatives memory: 68K
[ 6.019644] Freeing unused decrypted memory: 2028K
[ 6.032489] Freeing unused kernel image (initmem) memory: 4064K
[ 6.075487] Freeing unused kernel image (rodata/data gap) memory: 1476K

Both the "Generic" and "Huge" kernels freed 2028K of "decrypted" memory, and
all the init memory that they had allocated. The "Generic" kernel also freed
9420K of memory reserved for the initrd (something that the "Huge" kernel
doesn't have).
The "Generic" kernel loaded less "kernel" (37414K vs the "Huge" 41049K), but
/overall/ loaded more when you consider the size of the initrd (46834K vs the
"Huge" 41049K).
So, the "Huge" kernel has a bit larger resident size, but a smaller loader
footprint than the "Generic" kernel.

Post by Chris Elvidge
dmsg-memory-huge-6.8.6
[ 0.028539] PM: hibernation: Registered nosave memory: [mem
0x00000000-0x00000fff]
[ 0.028543] PM: hibernation: Registered nosave memory: [mem
0x0009f000-0x0009ffff]
[ 0.028544] PM: hibernation: Registered nosave memory: [mem
0x000a0000-0x000effff]
[ 0.028545] PM: hibernation: Registered nosave memory: [mem
0x000f0000-0x000fffff]
[ 0.051606] Memory: 3035204K/3145272K available (24576K kernel code,
3653K rwdata, 8864K rodata, 4092K init, 3404K bss, 109808K reserved, 0K
cma-reserved)
[ 0.153368] Freeing SMP alternatives memory: 68K
[ 5.951739] Freeing unused decrypted memory: 2028K
[ 5.967211] Freeing unused kernel image (initmem) memory: 4092K
[ 5.998271] Freeing unused kernel image (rodata/data gap) memory: 1376K
Looks to me as though it frees everything unused.

This "Huge" kernel seems to be only about 136K bigger than the 6.6.7 "Huge"
kernel (+8K rwdata, +100K rodata, +28K init), but has a smaller bss (by
104K).

Yes. I think I'll stick to compiling huge kernels and not bother with
(and reblacklist) generic. It seems that the 'original' advice
'generic/initrd to save memory' doesn't hold water.

Not purely Slack related, but . . .

I see Oracle have now fixed the strlcpy/strscpy problem with 6.8 kernels
- VirtualBox 7.0.16. Saves a search and replace job.

Still can't get over the vmwgfx problem, though.
[ 11.409314] vmwgfx 0000:00:02.0: [drm] *ERROR* vmwgfx seems to be
running on an unsupported hypervisor.
[ 11.409319] vmwgfx 0000:00:02.0: [drm] *ERROR* This configuration is
likely broken.
[ 11.409322] vmwgfx 0000:00:02.0: [drm] *ERROR* Please switch to a
supported graphics device to avoid problems.

Still it seems to work OK.