On 06/20/2018 07:00 AM, Michal Hocko wrote: > On Fri 15-06-18 15:36:07, Jason Baron wrote: >> >> >> On 06/13/2018 03:15 AM, Michal Hocko wrote: >>> On Wed 13-06-18 08:32:19, Vlastimil Babka wrote: > [...] >>>> BTW I didn't get why we should allow this for MADV_DONTNEED but not >>>> MADV_FREE. Can you expand on that? >>> >>> Well, I wanted to bring this up as well. I guess this would require some >>> more hacks to handle the reclaim path correctly because we do rely on >>> VM_LOCK at many places for the lazy mlock pages culling. >>> >> >> The point of not allowing MADV_FREE on mlock'd pages for me was that >> with mlock and even MLOCK_ON_FAULT, one can always can always determine >> if a page is present or not (and thus avoid the major fault). Allowing >> MADV_FREE on lock'd pages breaks that assumption. > > But once you have called MADV_FREE you cannot assume anything about the > content until you touch the memory again. So you can safely assume a > major fault for the worst case. Btw. why knowing whether you major fault > is important in the first place? What is an application going to do > about that information? > Fair enough, I think that means you end up with a MADV_FREE_FORCE to support that case? As I said I worked around this by using tmpfs and fallocate(FALLOC_FL_PUNCH_HOLE). However, I still think there is a use-case for doing this for anonymous memory, to avoid the unlock() calls. The use-case I had in mind was simply an application that has a fast path for when it knows that the requested item is locked in memory. Thanks, -Jason -- To unsubscribe from this list: send the line "unsubscribe linux-api" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
