On Wed 18-10-17 16:17:30, Shakeel Butt wrote: > Recently we have observed high latency in mlock() in our generic > library and noticed that users have started using tmpfs files even > without swap and the latency was due to expensive remote LRU cache > draining.
some numbers would be really nice > Is lru_add_drain_all() required by mlock()? The answer is no and the > reason it is still in mlock() is to rapidly move mlocked pages to > unevictable LRU. Is this really true? lru_add_drain_all will flush the previously cached LRU pages. We are not flushing after the pages have been faulted in so this might not do anything wrt. mlocked pages, right? > Without lru_add_drain_all() the mlocked pages which > were on pagevec at mlock() time will be moved to evictable LRUs but > will eventually be moved back to unevictable LRU by reclaim. So, we > can safely remove lru_add_drain_all() from mlock(). Also there is no > need for local lru_add_drain() as it will be called deep inside > __mm_populate() (in follow_page_pte()). Anyway, I do agree that lru_add_drain_all here is pointless. Either we should drain after the memory has been faulted in and mlocked or not at all. So the patch looks good to me I am just not sure about the changelog. > Signed-off-by: Shakeel Butt <[email protected]> > --- > mm/mlock.c | 5 ----- > 1 file changed, 5 deletions(-) > > diff --git a/mm/mlock.c b/mm/mlock.c > index dfc6f1912176..3ceb2935d1e0 100644 > --- a/mm/mlock.c > +++ b/mm/mlock.c > @@ -669,8 +669,6 @@ static __must_check int do_mlock(unsigned long start, > size_t len, vm_flags_t fla > if (!can_do_mlock()) > return -EPERM; > > - lru_add_drain_all(); /* flush pagevec */ > - > len = PAGE_ALIGN(len + (offset_in_page(start))); > start &= PAGE_MASK; > > @@ -797,9 +795,6 @@ SYSCALL_DEFINE1(mlockall, int, flags) > if (!can_do_mlock()) > return -EPERM; > > - if (flags & MCL_CURRENT) > - lru_add_drain_all(); /* flush pagevec */ > - > lock_limit = rlimit(RLIMIT_MEMLOCK); > lock_limit >>= PAGE_SHIFT; > > -- > 2.15.0.rc1.287.g2b38de12cc-goog > -- Michal Hocko SUSE Labs
