On 16.11.21 22:37, Andrew Morton wrote: > On Tue, 16 Nov 2021 20:48:48 +0100 "Drew DeVault" <sir@xxxxxxxxx> wrote: > >> On Tue Nov 16, 2021 at 8:47 PM CET, Andrew Morton wrote: >>> Well, why change the default? Surely anyone who cares is altering it >>> at runtime anyway. And if they are not, we should encourage them to do >>> so? >> >> I addressed this question in the original patch's commit message. > > Kinda. > > We're never going to get this right, are we? The only person who can > decide on a system's appropriate setting is the operator of that > system. Haphazardly increasing the limit every few years mainly > reduces incentive for people to get this right. > > And people who test their software on 5.17 kernels will later find that > it doesn't work on 5.16 and earlier, so they still need to tell their > users to configure their systems appropriately. Until 5.16 is > obsolete, by which time we're looking at increasing the default again. > > I don't see how this change gets us closer to the desired state: > getting distros and their users to configure their systems > appropriately. > My 2 cents: while we should actually try to avoid new FOLL_LONGTERM users where possible, we introduce more (IOURING_REGISTER_BUFFERS) to be consumed by ordinary, unprivileged users. These new features, *when used* require us to raise the MLOCK_LIMIT. Secretmem is similar, but for now it rather "replaces" old mlock usage and IIRC has similarly small memory demands; that might change in the future, though. Why is FOLL_LONGTERM bad? Not only does it prevent swapping like mlock does, the pages are also unmovable in memory, such that they cannot be moved around, for example, for memory compaction. Well, I'm not too mad about IOURING_REGISTER_BUFFERS, it actually helped me to write a simple reproducer for the COW issues we have in upstream mm, and can be quite beneficial in some setups. Still, I think it should be used with care depending on the actual environment. So, just because a new feature is around that could be used, does it mean that we should adjust our kernel default? I'd say in this case, rather not. Distributions, or much better, the responsible admin, should make such decisions, knowing the environment and the effect this could have. (I know that we can similarly trigger allocation of a lot of unmovable memory using other means by malicious user space; but that is rather something to limit or handle in the future IMHO) -- Thanks, David / dhildenb
