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.
