On Thu 18-06-15 16:30:48, Eric B Munson wrote: > On Thu, 18 Jun 2015, Michal Hocko wrote: [...] > > Wouldn't it be much more reasonable and straightforward to have > > MAP_FAULTPOPULATE as a counterpart for MAP_POPULATE which would > > explicitly disallow any form of pre-faulting? It would be usable for > > other usecases than with MAP_LOCKED combination. > > I don't see a clear case for it being more reasonable, it is one > possible way to solve the problem. MAP_FAULTPOPULATE would be usable for other cases as well. E.g. fault around is all or nothing feature. Either all mappings (which support this) fault around or none. There is no way to tell the kernel that this particular mapping shouldn't fault around. I haven't seen such a request yet but we have seen requests to have a way to opt out from a global policy in the past (e.g. per-process opt out from THP). So I can imagine somebody will come with a request to opt out from any speculative operations on the mapped area in the future. > But I think it leaves us in an even > more akward state WRT VMA flags. As you noted in your fix for the > mmap() man page, one can get into a state where a VMA is VM_LOCKED, but > not present. Having VM_LOCKONFAULT states that this was intentional, if > we go to using MAP_FAULTPOPULATE instead of MAP_LOCKONFAULT, we no > longer set VM_LOCKONFAULT (unless we want to start mapping it to the > presence of two MAP_ flags). This can make detecting the MAP_LOCKED + > populate failure state harder. I am not sure I understand your point here. Could you be more specific how would you check for that and what for? >From my understanding MAP_LOCKONFAULT is essentially MAP_FAULTPOPULATE|MAP_LOCKED with a quite obvious semantic (unlike single MAP_LOCKED unfortunately). I would love to also have MAP_LOCKED|MAP_POPULATE (aka full mlock semantic) but I am really skeptical considering how my previous attempt to make MAP_POPULATE reasonable went. > If this is the preferred path for mmap(), I am fine with that. > However, > I would like to see the new system calls that Andrew mentioned (and that > I am testing patches for) go in as well. mlock with flags sounds like a good step but I am not sure it will make sense in the future. POSIX has screwed that and I am not sure how many applications would use it. This ship has sailed long time ago. > That way we give users the > ability to request VM_LOCKONFAULT for memory allocated using something > other than mmap. mmap(MAP_FAULTPOPULATE); mlock() would have the same semantic even without changing mlock syscall. > > > This patch introduces the ability to request that pages are not > > > pre-faulted, but are placed on the unevictable LRU when they are finally > > > faulted in. > > > > > > To keep accounting checks out of the page fault path, users are billed > > > for the entire mapping lock as if MAP_LOCKED was used. > > > > > > Signed-off-by: Eric B Munson <emunson@xxxxxxxxxx> > > > Cc: Michal Hocko <mhocko@xxxxxxx> > > > Cc: linux-alpha@xxxxxxxxxxxxxxx > > > Cc: linux-kernel@xxxxxxxxxxxxxxx > > > Cc: linux-mips@xxxxxxxxxxxxxx > > > Cc: linux-parisc@xxxxxxxxxxxxxxx > > > Cc: linuxppc-dev@xxxxxxxxxxxxxxxx > > > Cc: sparclinux@xxxxxxxxxxxxxxx > > > Cc: linux-xtensa@xxxxxxxxxxxxxxxx > > > Cc: linux-mm@xxxxxxxxx > > > Cc: linux-arch@xxxxxxxxxxxxxxx > > > Cc: linux-api@xxxxxxxxxxxxxxx > > > --- [...] -- Michal Hocko SUSE Labs -- To unsubscribe from this list: send the line "unsubscribe linux-api" in
