| Message ID | 20240322093555.226789-3-liushixin2@huawei.com (mailing list archive) |
|---|---|
| State | New |
| Headers | show |
| Series | Fix I/O high when memory almost met memcg limit | expand |
On Fri 22-03-24 17:35:55, Liu Shixin wrote: > If there are too many folios that are recently evicted in a file, then > they will probably continue to be evicted. In such situation, there is > no positive effect to read-ahead this file since it is only a waste of IO. > > The mmap_miss is increased in do_sync_mmap_readahead() and decreased in > both do_async_mmap_readahead() and filemap_map_pages(). In order to skip > read-ahead in above scenario, the mmap_miss have to increased exceed > MMAP_LOTSAMISS. This can be done by stop decreased mmap_miss when folio > has workingset flags. The async path is not to care because in above > scenario, it's hard to run into the async path. > > Signed-off-by: Liu Shixin <liushixin2@huawei.com> ... > diff --git a/mm/filemap.c b/mm/filemap.c > index 8df4797c5287..753771310127 100644 > --- a/mm/filemap.c > +++ b/mm/filemap.c > @@ -3439,7 +3439,8 @@ static vm_fault_t filemap_map_folio_range(struct vm_fault *vmf, > if (PageHWPoison(page + count)) > goto skip; > > - (*mmap_miss)++; > + if (!folio_test_workingset(folio)) > + (*mmap_miss)++; Hum, so this means we consider this a 'hit' if the page is completely new in the page cache or evicted long time ago. OK, makes sense. It would be nice to add a comment in this direction to explain the condition. Frankly the whole mmap_miss accounting is broken as I've outlined in my patch series. But I guess this works as a fixup for your immediate problem and we can make mmap_miss accounting sensible later. So for now feel free to add: Reviewed-by: Jan Kara <jack@suse.cz> Honza
diff --git a/mm/filemap.c b/mm/filemap.c index 8df4797c5287..753771310127 100644 --- a/mm/filemap.c +++ b/mm/filemap.c @@ -3439,7 +3439,8 @@ static vm_fault_t filemap_map_folio_range(struct vm_fault *vmf, if (PageHWPoison(page + count)) goto skip; - (*mmap_miss)++; + if (!folio_test_workingset(folio)) + (*mmap_miss)++; /* * NOTE: If there're PTE markers, we'll leave them to be @@ -3488,7 +3489,8 @@ static vm_fault_t filemap_map_order0_folio(struct vm_fault *vmf, if (PageHWPoison(page)) return ret; - (*mmap_miss)++; + if (!folio_test_workingset(folio)) + (*mmap_miss)++; /* * NOTE: If there're PTE markers, we'll leave them to be
If there are too many folios that are recently evicted in a file, then they will probably continue to be evicted. In such situation, there is no positive effect to read-ahead this file since it is only a waste of IO. The mmap_miss is increased in do_sync_mmap_readahead() and decreased in both do_async_mmap_readahead() and filemap_map_pages(). In order to skip read-ahead in above scenario, the mmap_miss have to increased exceed MMAP_LOTSAMISS. This can be done by stop decreased mmap_miss when folio has workingset flags. The async path is not to care because in above scenario, it's hard to run into the async path. Signed-off-by: Liu Shixin <liushixin2@huawei.com> --- mm/filemap.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-)