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