On Wed, Feb 12, 2020 at 11:22:06AM +0100, Jan Kara wrote: > On Mon 10-02-20 16:19:58, Minchan Kim wrote: > > Basically, fault handler releases mmap_sem before requesting readahead > > and then it is supposed to retry lookup the page from page cache with > > FAULT_FLAG_TRIED so that it avoids the live lock of infinite retry. > > > > However, what happens if the fault handler find a page from page > > cache and the page has readahead marker but are waiting under > > writeback? Plus one more condition, it happens under mm_populate > > which repeats faulting unless it encounters error. So let's assemble > > conditions below. > > > > __mm_populate > > for (...) > > get_user_pages(faluty_address) > > handle_mm_fault > > filemap_fault > > find a page form page(PG_uptodate|PG_readahead|PG_writeback) > > it will return VM_FAULT_RETRY > > continue with faulty_address > > > > IOW, it will repeat fault retry logic until the page will be written > > back in the long run. It makes big spike latency of several seconds. > > > > This patch solves the issue by turning off fault retry logic in second > > trial. > > > > Signed-off-by: Minchan Kim <minchan@xxxxxxxxxx> > > --- > > It was orignated from code review once I have seen several user reports > > but didn't confirm yet it's the root cause. > > Yes, I think the immediate problem is actually elsewhere but I agree that > __mm_populate() should follow the general protocol of retrying only once > so your change should make it more robust. The patch looks good to me, you > can add: > > Reviewed-by: Jan Kara <jack@xxxxxxx> Thanks for the review!
