On Fri, Aug 8, 2025 at 10:46 AM Dave Young <[email protected]> wrote: > > On Fri, 8 Aug 2025 at 10:30, Dave Young <[email protected]> wrote: > > > > Hi Lichen, > > > > On Fri, 8 Aug 2025 at 09:55, Lichen Liu <[email protected]> wrote: > > > > > > 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 <[email protected]> > > > --- > > > 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; > > > > I do see there are a few similar usages in init/do_mounts.c, probably > > it is old stuff and it just works. But I think making rootfs_flags as > > an array and copying str into it is the right way. Hi Dave, thanks for your comments!
I will check how to make it better. > > Another question, may need fs people to clarify. If the mount is > tmpfs and it is also rootfs, could it use 100% of the memory by > default, and then no need for an extra param? I feel that there is > no point to reserve memory if it is a fully memory based file system. > I think rootfstype=ramfs will use 100% of the memory. For kdump only, there might not be much difference between using ramfs and tmpfs size=100%. But I think it might provide more flexibility since rootfstype= and rootflags= can be used with root=. https://www.kernel.org/doc/html/latest/admin-guide/kernel-parameters.html > > > > > + 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 > > > > > > > > Thanks > > Dave >
