From: chris@mshome.net   
      
   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   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)