lkml.org 
[lkml]   [2020]   [Nov]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH v8 2/9] mmap: make mlock_future_check() global
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.

\
 
 \ /
  Last update: 2020-11-17 17:00    [W:0.064 / U:0.120 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site