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

--
Chris Elvidge, England
I AM NOT MY LONG-LOST TWIN

On Tue, 16 Apr 2024 14:33:47 +0100, Chris Elvidge wrote:

> 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
--
Lew Pitcher
"In Skills We Trust"

On 16/04/2024 at 14:51, Lew Pitcher wrote:
> On Tue, 16 Apr 2024 14:33:47 +0100, Chris Elvidge wrote:
>
>> 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, England
RALPH WON'T "MORPH" IF YOU SQUEEZE HIM HARD ENOUGH

On 16/04/2024 at 14:51, Lew Pitcher wrote:
> On Tue, 16 Apr 2024 14:33:47 +0100, Chris Elvidge wrote:
>
>> 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'

--
Chris Elvidge, England
I WILL NOT USE ABBREV.

On Tue, 16 Apr 2024 16:40:19 +0100, Chris Elvidge wrote:

> On 16/04/2024 at 14:51, Lew Pitcher wrote:
>> On Tue, 16 Apr 2024 14:33:47 +0100, Chris Elvidge wrote:
>>
>>> 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.

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.

> 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. :-)

--
Lew Pitcher
"In Skills We Trust"

On 16/04/2024 at 18:19, Lew Pitcher wrote:
>
> 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.

--
Chris Elvidge, England
I WILL TRY TO RAISE A BETTER CHILD

On Tue, 16 Apr 2024 19:17:35 +0100, Chris Elvidge wrote:

> On 16/04/2024 at 18:19, Lew Pitcher wrote:
>>
>> 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.

> [ 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.

>
> 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).

--
Lew Pitcher
"In Skills We Trust"

On 16/04/2024 at 22:38, Lew Pitcher wrote:
> On Tue, 16 Apr 2024 19:17:35 +0100, Chris Elvidge wrote:
>
>> On 16/04/2024 at 18:19, Lew Pitcher wrote:
>>>
>>> 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.
>
>
>> [ 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.
>
>>
>> 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.

--
Chris Elvidge, England
HIGH EXPLOSIVES AND SCHOOL DON'T MIX