On Tue 23-06-15 14:45:17, Vlastimil Babka wrote: > On 06/22/2015 04:18 PM, Eric B Munson wrote: > >On Mon, 22 Jun 2015, Michal Hocko wrote: > > > >>On Fri 19-06-15 12:43:33, Eric B Munson wrote: [...] > >>>My thought on detecting was that someone might want to know if they had > >>>a VMA that was VM_LOCKED but had not been made present becuase of a > >>>failure in mmap. We don't have a way today, but adding VM_LOCKONFAULT > >>>is at least explicit about what is happening which would make detecting > >>>the VM_LOCKED but not present state easier. > >> > >>One could use /proc/<pid>/pagemap to query the residency. > > I think that's all too much complex scenario for a little gain. If someone > knows that mmap(MAP_LOCKED|MAP_POPULATE) is not perfect, he should either > mlock() separately from mmap(), or fault the range manually with a for loop. > Why try to detect if the corner case was hit? No idea. I have just offered a way to do that. I do not think it is anyhow useful but who knows... I do agree that the mlock should be used for the full mlock semantic. > >>>This assumes that > >>>MAP_FAULTPOPULATE does not translate to a VMA flag, but it sounds like > >>>it would have to. > >> > >>Yes, it would have to have a VM flag for the vma. > > So with your approach, VM_LOCKED flag is enough, right? The new MAP_ / > MLOCK_ flags just cause setting VM_LOCKED to not fault the whole vma, but > otherwise nothing changes. VM_FAULTPOPULATE would have to be sticky to prevent from other speculative poppulation of the mapping. I mean, is it OK to have a new mlock semantic (on fault) which might still populate&lock memory which hasn't been faulted directly? Who knows what kind of speculative things we will do in the future and then find out that the semantic of lock-on-fault is not usable anymore. [...] -- Michal Hocko SUSE Labs
