Lichen Liu <lich...@redhat.com>: > When CONFIG_TMPFS is enabled, the initial root filesystem is a tmpfs. > By default, a tmpfs mount is limited to using 50% of the available RAM > for its content. This can be problematic in memory-constrained > environments, particularly during a kdump capture. > > In a kdump scenario, the capture kernel boots with a limited amount of > memory specified by the 'crashkernel' parameter. If the initramfs is > large, it may fail to unpack into the tmpfs rootfs due to insufficient > space. This is because to get X MB of usable space in tmpfs, 2*X MB of > memory must be available for the mount. This leads to an OOM failure > during the early boot process, preventing a successful crash dump. > > This patch introduces a new kernel command-line parameter, rootfsflags, > which allows passing specific mount options directly to the rootfs when > it is first mounted. This gives users control over the rootfs behavior. > > For example, a user can now specify rootfsflags=size=75% to allow the > tmpfs to use up to 75% of the available memory. This can significantly > reduce the memory pressure for kdump. > > Consider a practical example: > > To unpack a 48MB initramfs, the tmpfs needs 48MB of usable space. With > the default 50% limit, this requires a memory pool of 96MB to be > available for the tmpfs mount. The total memory requirement is therefore > approximately: 16MB (vmlinuz) + 48MB (loaded initramfs) + 48MB (unpacked > kernel) + 96MB (for tmpfs) + 12MB (runtime overhead) ≈ 220MB. > > By using rootfsflags=size=75%, the memory pool required for the 48MB > tmpfs is reduced to 48MB / 0.75 = 64MB. This reduces the total memory > requirement by 32MB (96MB - 64MB), allowing the kdump to succeed with a > smaller crashkernel size, such as 192MB. > > An alternative approach of reusing the existing rootflags parameter was > considered. However, a new, dedicated rootfsflags parameter was chosen > to avoid altering the current behavior of rootflags (which applies to > the final root filesystem) and to prevent any potential regressions. > > This approach is inspired by prior discussions and patches on the topic. > Ref: https://www.lightofdawn.org/blog/?viewDetailed=00128 > Ref: https://landley.net/notes-2015.html#01-01-2015 > Ref: https://lkml.org/lkml/2021/6/29/783 > Ref: > https://www.kernel.org/doc/html/latest/filesystems/ramfs-rootfs-initramfs.html#what-is-rootfs > > Signed-off-by: Lichen Liu <lich...@redhat.com> > --- > fs/namespace.c | 11 ++++++++++- > 1 file changed, 10 insertions(+), 1 deletion(-) > > diff --git a/fs/namespace.c b/fs/namespace.c > index ddfd4457d338..a450db31613e 100644 > --- a/fs/namespace.c > +++ b/fs/namespace.c > @@ -65,6 +65,15 @@ static int __init set_mphash_entries(char *str) > } > __setup("mphash_entries=", set_mphash_entries); > > +static char * __initdata rootfs_flags; > +static int __init rootfs_flags_setup(char *str) > +{ > + rootfs_flags = str; > + return 1; > +} > + > +__setup("rootfsflags=", rootfs_flags_setup); > + > static u64 event; > static DEFINE_XARRAY_FLAGS(mnt_id_xa, XA_FLAGS_ALLOC); > static DEFINE_IDA(mnt_group_ida); > @@ -6086,7 +6095,7 @@ static void __init init_mount_tree(void) > struct mnt_namespace *ns; > struct path root; > > - mnt = vfs_kern_mount(&rootfs_fs_type, 0, "rootfs", NULL); > + mnt = vfs_kern_mount(&rootfs_fs_type, 0, "rootfs", rootfs_flags); > if (IS_ERR(mnt)) > panic("Can't create rootfs"); > > -- > 2.50.1
Thank you for this patch! I suggest periodically check linux-next to see whether the patch got there. If it was not applied in resonable time, then resend it. But this time, please, clearly specify tree, which should accept it. I think the most apropriate tree is VFS tree here. So, when resending please add linux-fsde...@vger.kernel.org to CC and say in first paragraph in your mail that the patch is for VFS tree. -- Askar Safin
