shmem: add shmem_size option, set filesystem size
Subsystems (3)
PATCH 1/1 shmem: add shmem_size option, set filesystem size
Adds a kernel configuration option and command line parameter to specify the size of the shmem filesystem. It is currently hard-coded to 50% of memory. Users should have the option to set this value as they see fit.
A specific case where this is necessary would be if the initramfs were larger than half of the memory, such as a 2.5GB filesystem with 4GB of memory. Without this option, this causes a kernel panic. With this option, the user may specify something like 75%, which would allow the filesystem into memory, while still leaving enough resources to run a functioning system.
This patch creates the SHMEM_SIZE configuration option and the shmem_size parameter, which may be specified in bytes, human notation (1G, 100M, etc.) or percentage (75%). The default remains unchanged. This patch has no impact unless the values are changed.
--- Documentation/admin-guide/kernel-parameters.rst | 1 + Documentation/admin-guide/kernel-parameters.txt | 5 +++ init/Kconfig | 8 ++++ mm/shmem.c | 57 +++++++++++++++++++++++-- 4 files changed, 67 insertions(+), 4 deletions(-)
Documentation/admin-guide/kernel-parameters.rst +1 -0
@@ -149,6 +149,7 @@ parameter is applicable:: APPARMOR AppArmor support is enabled. SERIAL Serial support is enabled. SH SuperH architecture is enabled. + SHMEM Full shmem filesystem is enabled. SMP The kernel is an SMP kernel. SPARC Sparc architecture is enabled. SWSUSP Software suspend (hibernation) is enabled.
Documentation/admin-guide/kernel-parameters.txt +5 -0
@@ -4307,6 +4307,11 @@ shapers= [NET] Maximal number of shapers. + shmem_size= [SHMEM] + Size of shmem filesystem. Can be specified as a plain + integer, in memory size notation (such as 1024M or 1G), + or as a percentage (50%). + simeth= [IA-64] simscsi=
init/Kconfig +8 -0
@@ -1537,6 +1537,14 @@ config SHMEM option replaces shmem and tmpfs with the much simpler ramfs code, which may be appropriate on small systems without swap. +config SHMEM_SIZE + string "Hard-set the shmem filesystem size" + default 0 + depends on SHMEM + help + Size of shmem filesystem. Can be specified as a plain integer, in + memory size notation (such as 1024M or 1G), or as a percentage (50%). + config AIO bool "Enable AIO support" if EXPERT default y
mm/shmem.c +53 -4
81 lines not on this page · raw message
--
2.15.2
Quoted 10 lines · Gary B. Genett
A specific case where this is necessary would be if the initramfs were larger than half of the memory, such as a 2.5GB filesystem with 4GB of memory. Without this option, this causes a kernel panic. With this option, the user may specify something like 75%, which would allow the filesystem into memory, while still leaving enough resources to run a functioning system.
Why would anyone need such a large an initramfs?
Quoted 8 lines
Quoted 6 lines
A specific case where this is necessary would be if the initramfs were larger than half of the memory, such as a 2.5GB filesystem with 4GB of memory. Without this option, this causes a kernel panic. With this option, the user may specify something like 75%, which would allow the filesystem into memory, while still leaving enough resources to run a functioning system.
Why would anyone need such a large an initramfs?
Thank you for such a quick response, Qian! I really appreciate your question and consideration of my submission.
The use case here is a live distribution, where the initramfs is a standard filesystem. It is common for these types of distributions to unpack root into memory. Most of them use SquashFS, and resize shmem using a smaller initramfs first.
In my case, I am unpacking straight from the initramfs to alleviate the need for a separate file and packaging everything in an ISO. It very well could be that I am the only person who has ever needed this, but it has been a requirement for my distribution.
https://sourceforge.net/projects/gary-os
https://github.com/garybgenett/gary-os
It is also possible that other live distributions are taking the approach they are because of the current inability to load an initrd/initramfs directly into memory without manually resizing the shmem filesystem first.
Since I was in there hacking the feature, anyway, I thought it would be worth submitting.
At the least, it should be a "#define", or something. Right now it is a hard-coded magic token.
Thoughts?
-- Gary
Quoted 10 lines · -Gary-
The use case here is a live distribution, where the initramfs is a standard filesystem. It is common for these types of distributions to unpack root into memory. Most of them use SquashFS, and resize shmem using a smaller initramfs first.
In my case, I am unpacking straight from the initramfs to alleviate the need for a separate file and packaging everything in an ISO. It very well could be that I am the only person who has ever needed this, but it has been a requirement for my distribution.
Quoted 8 lines
https://sourceforge.net/projects/gary-os
https://github.com/garybgenett/gary-osIt is also possible that other live distributions are taking the approach they are because of the current inability to load an initrd/initramfs directly into memory without manually resizing the shmem filesystem first.
Since I was in there hacking the feature, anyway, I thought it would be worth submitting.
At the least, it should be a "#define", or something. Right now it is a hard-coded magic token.
I am not sure if it worth the complication. Right now, you have the choice of resizing shmem like every body else or increasing your system memory a bit.
If there are more compiling reasons to bump the limit, it is probably more appropriate to make it the default to use something like 75% memory if there isn’t much side-effect.
Quoted 5 lines
Quoted 1 line
At the least, it should be a "#define", or something. Right now it is a hard-coded magic token.
I am not sure if it worth the complication. Right now, you have the choice of resizing shmem like every body else or increasing your system memory a bit.
If there are more compiling reasons to bump the limit, it is probably more appropriate to make it the default to use something like 75% memory if there isn’t much side-effect.
Thank you again, Qian. I appreciate the conversation and coaching!
That makes perfect sense. I agree with the effort to keep things tidy, efficient and supportable. With your blessing, I will submit a separate patch that only adds a configuration option to set the number of pages, and does not perform any additional math or steps other than reporting the value. This will at least make it a defined value rather than a magic token, and will allow any expert users who need it to change the value.
I'm very reluctant, if not outright opposed, to changing the default, regardless of how compelling the case. The possible side-effects of that change in behavior are unforeseen, and the scope of testing required is infeasible. I sense that you agree with this.
I hope my subsequent patch is low-impact enough to be accepted.
It means a lot that you took the time to review and comment on my work. I do greatly appreciate it. This was my first kernel patch submission, and you made it a good experience. <^)
-- Gary