Closed vmx closed 2 years ago
From the man page
MAP_LOCKED (since Linux 2.5.37)
Mark the mapped region to be locked in the same way as mlock(2). This implementation will try to populate (prefault) the whole range but the mmap() call doesn't fail with ENOMEM if this fails. Therefore major faults might happen later on. So the
semantic is not as strong as mlock(2). One should use mmap() plus mlock(2) when major faults are not acceptable after the initialization of the mapping. The MAP_LOCKED flag is ignored in older kernels.
Since it can fail silently, maybe it would be better to provide only lock
and unlock
methods and ignore the flag?
Otherwise, it should be handled just like MAP_POPULATE
IMHO.
What I wondered about in the initial PR is whether can have at least some tests for the lock/unlock functionality. What is resource limit for locking memory in GitHub actions? Would that be sufficient for a small test case?
Since it can fail silently, maybe it would be better to provide only
lock
andunlock
methods and ignore the flag?
That sounds like a good idea.
Do I understand the mmap documentation correctly, that if I would want to have a similar to the MAP_LOCKED
flag, I'd call populate()
and the mlock()
? That should work for my use case (populate()
wasn't a thing at the time of the fork).
So I'll do a PR with lock()
and unlock()
only (I guess the names should be without the leading "m", just as advise()
).
I wanted to do a test, but I couldn't think of a way to do it. How would I test that a page is actually locked? Did you think of creating a lock of a mmap that is bigger than the available memory which then should fail as it won't swap?
Do I understand the mmap documentation correctly, that if I would want to have a similar to the MAP_LOCKED flag, I'd call populate() and the mlock()? That should work for my use case (populate() wasn't a thing at the time of the fork).
From the man page
mlock(), mlock2(), and munlock()
mlock() locks pages in the address range starting at addr and continuing for len bytes. All pages that contain a part of the specified address range are guaranteed to be resident in RAM when the call returns successfully; the pages are guaranteed to stay
in RAM until later unlocked.
I would assume that MAP_POPULATE
is not even necessary.
I wanted to do a test, but I couldn't think of a way to do it. How would I test that a page is actually locked? Did you think of creating a lock of a mmap that is bigger than the available memory which then should fail as it won't swap?
I was thinking about having the test make the system calls without errors would be helpful already. Theoretically /proc/self/smaps
could be checked to determine if the range is locked into memory, but I think that might be a bit too much (and too specific to Linux).
Around the same time of this fork, there was a fork started called
mapr
, which implementedMAP_PRIVATE
,MAP_LOCK
andmlock
. All use cases forMAP_PRIVATE
are now covered bymemmap2
through function calls. Thanks for pointing that out at https://github.com/RazrFalcon/memmap2-rs/pull/50#discussion_r937831664.What is left from that fork, what
memmap2
is missing isMAP_LOCK
andmlock
. Before I do another PR, I'd like to check what the best way would be, hence this issue.The only use-case for
MAP_LOCK
we currently have in our code base is in combination withmap_anon
. Should it only be added there? Or should it be added to all methods (similar toMAP_POPULATE
as I did in at https://github.com/RazrFalcon/memmap2-rs/pull/50?I think for adding
mlock()
there aren't any questions.