On Tue, Nov 17, 2020 at 04:09:39PM +0100, David Hildenbrand wrote:

On 15.11.20 09:26, Mike Rapoport wrote:

quoted

On Thu, Nov 12, 2020 at 09:15:18PM +0100, David Hildenbrand wrote:

...

quoted

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.

quoted

quoted

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

quoted

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.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel