On 2019/11/5 20:45, Michal Hocko wrote: > On Tue 05-11-19 20:28:58, zhong jiang wrote: >> On 2019/11/5 14:33, Michal Hocko wrote: >>> On Sat 02-11-19 15:36:55, zhong jiang wrote: >>>> On 2019/11/2 2:32, Michal Hocko wrote: >>> [...] >>>>> But I would really appreciate to add a comment for the BUG_ON and >>>>> explain why do we care about PageUnevictable so much when there is an >>>>> explicit page_evictable check in the reclaim path. In other words a >>>>> short summary of what Johannes explained in >>>>> http://lkml.kernel.org/r/20191030193307.GA48128@xxxxxxxxxxx. Maybe in a >>>>> separate patch. Care to send one or should I send it? >>>> Hi, Michal >>>> >>>> Actually, I am not very clear about the words Johannes had said. How the race to >>>> tirgger, it will result in an PgeMlocked page can be visible in shrink_page_list. >>>> >>>> Could you elaborate the race in detail further ? >>> I would go with the following comment >>> >>> /* >>> * Page reclaim can see !page_evictable(), but it must not see pages that >>> * have the PageUnevictable lru bit already set. See __pagevec_lru_add_fn() >>> * for more details. >>> */ >> But the detail still confuses me in __pagevec_lru_add_fn() to see PageMlocked in vmscan :-\ . > Which part does confuse you exactly? page reclaim can see !page_evictable() means some race still exist in the kernel. Is there any race window . PageLocked will prevent the cases in shmem ?
