Re: [PATCH v8 2/9] mmap: make mlock_future_check() global

Mike Rapoport
2020-11-17T15:59:04Z

On Tue, Nov 17, 2020 at 04:09:39PM +0100, David Hildenbrand wrote:
> On 15.11.20 09:26, Mike Rapoport wrote:
> > On Thu, Nov 12, 2020 at 09:15:18PM +0100, David Hildenbrand wrote:

...

> > My thinking was that since secretmem does what mlock() does wrt
> > swapability, it should at least obey the same limit, i.e.
> > RLIMIT_MEMLOCK.
>
> Right, but at least currently, it behaves like any other CMA allocation
> (IIRC they are all unmovable and, therefore, not swappable). In the future,
> if pages would be movable (but not swappable), I guess it might makes more
> sense. I assume we never ever want to swap secretmem.
>
> "man getrlimit" states for RLIMIT_MEMLOCK:
>
> "This is the maximum number of bytes of memory that may be
> locked into RAM. [...] This limit affects
> mlock(2), mlockall(2), and the mmap(2) MAP_LOCKED operation.
> Since Linux 2.6.9, it also affects the shmctl(2) SHM_LOCK op‐
> eration [...]"
>
> So that place has to be updated as well I guess? Otherwise this might come
> as a surprise for users.

Sure.

> >
> > > E.g., we also don‘t
> > > account for gigantic pages - which might be allocated from CMA and are
> > > not swappable.
> > Do you mean gigantic pages in hugetlbfs?
>
> Yes
>
> > It seems to me that hugetlbfs accounting is a completely different
> > story.
>
> I'd say it is right now comparable to secretmem - which is why I though
> similar accounting would make sense.

IMHO, using RLIMIT_MEMLOCK and memcg is a more straightforward way than
a custom cgroup.

And if we'll see a need for additional mechanism, we can always add it.

> --
> Thanks,
>
> David / dhildenb
>
>

--
Sincerely yours,
Mike.