The base memory usage will be determined by the kernel modules loaded and the size in memory of those modules. The modules loaded will be based on the enumeration of your hardware. As kernels evolve, the hardware detected evolves and the memory allocated to support the hardware evolves too. Older kernels may have had simpler modules for your specific hardware or in some cases may not have initialized all the hardware. You can compare the output of lsmod on each kernel to compare and contrast memory usage. Other facets of memory allocation evolve over time as well, including buffer memory for things like network stack, socket management, firewall state table and related helper modules, reserved memory for paging, memory mapping of swap and more than I could list on HN. The same kernel you are using right now will have vastly different memory usage on physical bare metal vs. VM's and will vary by what devices are enumerated. Some of the older kernels (1.x) didn't even have dynamically loaded module support and may have only supported a limited set of your hardware.
The file size of the kernel will get bigger over time as more drivers are added for newer hardware. Only the drivers required for your hardware get loaded and thus the memory usage is independent of the kernels file size. If you custom build your kernel, you can strip out all of the drivers not required for your hardware if you had a need to do so. A legit need would be IoT devices that have limited persistent storage. Another use case would be if you were bored and wanted a learning exercise on building kernels or wanted to harden your kernel against specific threats or to add support for hardware without requiring a dynamically loaded module.
If you would like to get back towards a lower usage, some things you could potentially tinker with would be blacklisting drivers you do not need loaded and adjusting sysctl settings, pam limits, systemd unit file limits (does not apply to your 2.4 kernel) for more conservative memory limits based on your needs. Adjusting these things too low can cause problems or performance issues. Use care when blacklisting modules, as some modules depend on other modules and it is not always obvious why. The output of lsmod will show you some examples of the dependencies.
I'm sorry but that is totally not what I'm asking about.
I'm asking about the artificial HARDCODED limit despite the size of kernel or modules.
This is hardcoded at boot process - no matter how big or small your kernel is.
For example my 1.1 bare-bones uncompressed kernel [just basic modules] can work at 2MB of RAM, at size of ~700kb.
Almost the same uncompressed bare-bone kernel [just basic modules] from let's say 2.4 line requires 4MB of RAM - despite very similar size (~780kb).
My question is:
- Why there is such artificial and hard-coded limit in kernel source code?
- Why it was changed from 2MB to 4MB?
- Is it possible to change it back? In kernel source this is literally just simple "if ram < 4MB then error" - without any real kernel size check.
Sorry I misunderstood what you were asking. The answer is, not without recompiling the kernel. CONFIG_PHYSICAL_START has changed several times from 1.x, 2.4, 2.6+ to compensate for hardware comparability issues. There are probably other offsets that have changed as well. I suspect the best place to find the all-inclusive list of changes that are required prior to recompile would be on embeded device forums.
It would be very hard to look into this given the high-level description. If possible, please add links to the lines of code that you are referring to.
Have you looked at the commit that changed the line? There's probably some reasoning in the message, or some discussion the the mailing list for the patch that changed it. You can use https://archive.org/details/git-history-of-linux for versions pre-git.
The best way to see why something changed in Linux is to use git-blame and git-log. I know 1.3 and 2.4 didn't use git, but maybe there is an alternative or changelogs stored somewhere?
You could also change back to 2mb and see what explodes :)
I have old 386SX with 2MB of ram hanging around and I wonder:
- Why Linux requires 4MB of RAM no matter of kernel size?
- Why prior to Linux 1.3(?) I was able to use Linux with just 2MB of RAM (Slackware 2.1)
- Is it possible to modify "modern" kernel(let's say 2.4) (apart from lack of support for 386 anymore) to remove such artificial limit?
The base memory usage will be determined by the kernel modules loaded and the size in memory of those modules. The modules loaded will be based on the enumeration of your hardware. As kernels evolve, the hardware detected evolves and the memory allocated to support the hardware evolves too. Older kernels may have had simpler modules for your specific hardware or in some cases may not have initialized all the hardware. You can compare the output of lsmod on each kernel to compare and contrast memory usage. Other facets of memory allocation evolve over time as well, including buffer memory for things like network stack, socket management, firewall state table and related helper modules, reserved memory for paging, memory mapping of swap and more than I could list on HN. The same kernel you are using right now will have vastly different memory usage on physical bare metal vs. VM's and will vary by what devices are enumerated. Some of the older kernels (1.x) didn't even have dynamically loaded module support and may have only supported a limited set of your hardware.
The file size of the kernel will get bigger over time as more drivers are added for newer hardware. Only the drivers required for your hardware get loaded and thus the memory usage is independent of the kernels file size. If you custom build your kernel, you can strip out all of the drivers not required for your hardware if you had a need to do so. A legit need would be IoT devices that have limited persistent storage. Another use case would be if you were bored and wanted a learning exercise on building kernels or wanted to harden your kernel against specific threats or to add support for hardware without requiring a dynamically loaded module.
If you would like to get back towards a lower usage, some things you could potentially tinker with would be blacklisting drivers you do not need loaded and adjusting sysctl settings, pam limits, systemd unit file limits (does not apply to your 2.4 kernel) for more conservative memory limits based on your needs. Adjusting these things too low can cause problems or performance issues. Use care when blacklisting modules, as some modules depend on other modules and it is not always obvious why. The output of lsmod will show you some examples of the dependencies.
I'm sorry but that is totally not what I'm asking about.
I'm asking about the artificial HARDCODED limit despite the size of kernel or modules. This is hardcoded at boot process - no matter how big or small your kernel is.
For example my 1.1 bare-bones uncompressed kernel [just basic modules] can work at 2MB of RAM, at size of ~700kb.
Almost the same uncompressed bare-bone kernel [just basic modules] from let's say 2.4 line requires 4MB of RAM - despite very similar size (~780kb).
My question is:
- Why there is such artificial and hard-coded limit in kernel source code?
- Why it was changed from 2MB to 4MB?
- Is it possible to change it back? In kernel source this is literally just simple "if ram < 4MB then error" - without any real kernel size check.
Sorry I misunderstood what you were asking. The answer is, not without recompiling the kernel. CONFIG_PHYSICAL_START has changed several times from 1.x, 2.4, 2.6+ to compensate for hardware comparability issues. There are probably other offsets that have changed as well. I suspect the best place to find the all-inclusive list of changes that are required prior to recompile would be on embeded device forums.
It would be very hard to look into this given the high-level description. If possible, please add links to the lines of code that you are referring to.
Have you looked at the commit that changed the line? There's probably some reasoning in the message, or some discussion the the mailing list for the patch that changed it. You can use https://archive.org/details/git-history-of-linux for versions pre-git.
The best way to see why something changed in Linux is to use git-blame and git-log. I know 1.3 and 2.4 didn't use git, but maybe there is an alternative or changelogs stored somewhere?
You could also change back to 2mb and see what explodes :)