On Tue 28-04-15 16:10:01, Andrew Morton wrote: > On Tue, 28 Apr 2015 14:11:49 +0200 Michal Hocko <mhocko@xxxxxxx> wrote: > > > The man page however says > > " > > MAP_LOCKED (since Linux 2.5.37) > > Lock the pages of the mapped region into memory in the manner of > > mlock(2). This flag is ignored in older kernels. > > " > > I'm trying to remember why we implemented MAP_LOCKED in the first > place. Was it better than mmap+mlock in some fashion? > > afaict we had a #define MAP_LOCKED in the header file but it wasn't > implemented, so we went and wired it up. 13 years ago: > https://lkml.org/lkml/2002/9/18/108 Yeah I have encountered this one while digging though the history as well but there was no real usecase described - except "it doesn't work currently". The only sensible usecase I was able to come up with was a userspace fault handling when we need to mmap and lock the faulting address in an atomic way so that other threads cannot possibly leak data to the swap. These guys can live with the current implementation, though. I do not really believe that 2 instead of 1 syscall really justifies the complexity. > Anyway... the third way of doing this is to use plain old mmap() while > mlockall(MCL_FUTURE) is in force. Has anyone looked at that, checked > that the behaviour is sane and compared it with the mmap+mlock > behaviour, the MAP_LOCKED behaviour and the manpages? AFAICS this will behave the same way as mmap(MAP_LOCKED). VMA will be marked VM_LOCKED but the popullation might fail for the very same reason. -- Michal Hocko SUSE Labs -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>