Hi, On 5/15/23 01:34, Mike Rapoport wrote: > From: "Mike Rapoport (IBM)" <rppt@xxxxxxxxxx> > > Following the discussion about direct map fragmentaion at LSF/MM [1], it > appears that direct map fragmentation has a negligible effect on kernel > data accesses. Since the only reason that warranted secretmem to be > disabled by default was concern about performance regression caused by > the direct map fragmentation, it makes perfect sense to lift this > restriction and make secretmem enabled. > > secretmem obeys RLIMIT_MEMBLOCK and as such it is not expected to cause > large fragmentation of the direct map or meaningfull increase in page > tables allocated during split of the large mappings in the direct map. > > The secretmem.enable parameter is retained to allow system > administrators to disable secretmem at boot. > > Switch the default setting of secretem.enable parameter to 1. Nit: secretmem.enable Maybe fix up while applying. > > Link: https://lwn.net/Articles/931406/ [1] > Signed-off-by: Mike Rapoport (IBM) <rppt@xxxxxxxxxx> > --- > mm/secretmem.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/mm/secretmem.c b/mm/secretmem.c > index 0b502625cd30..974b32ba8b9d 100644 > --- a/mm/secretmem.c > +++ b/mm/secretmem.c > @@ -35,7 +35,7 @@ > #define SECRETMEM_MODE_MASK (0x0) > #define SECRETMEM_FLAGS_MASK SECRETMEM_MODE_MASK > > -static bool secretmem_enable __ro_after_init; > +static bool secretmem_enable __ro_after_init = 1; > module_param_named(enable, secretmem_enable, bool, 0400); > MODULE_PARM_DESC(secretmem_enable, > "Enable secretmem and memfd_secret(2) system call"); -- ~Randy
