On Thu 13-02-20 08:46:07, Matthew Wilcox wrote: > On Thu, Feb 13, 2020 at 08:48:47AM +0100, Michal Hocko wrote: > > Can we pursue on this please? An explicit NOFS scope annotation with a > > reference to compaction potentially locking up on pages in the readahead > > would be a great start. > > How about this (on top of the current readahead series): > > diff --git a/mm/readahead.c b/mm/readahead.c > index 29ca25c8f01e..32fd32b913da 100644 > --- a/mm/readahead.c > +++ b/mm/readahead.c > @@ -160,6 +160,16 @@ unsigned long page_cache_readahead_limit(struct address_space *mapping, > .nr_pages = 0, > }; > > + /* > + * Partway through the readahead operation, we will have added > + * locked pages to the page cache, but will not yet have submitted > + * them for I/O. Adding another page may need to allocate > + * memory, which can trigger memory migration. Telling the VM I would go with s@migration@compaction@ because it would make it more obvious that this is about high order allocations. The patch looks ok other than that but FS people would be better than me to give it a proper review. It would be great if you could mention that this shouldn't be a real problem for many(/most?) filesystems because they tend to have NOFS like mask in the the mapping but we would love to remove that in future hopefully so this change is really desiable. Thanks! > + * we're in the middle of a filesystem operation will cause it > + * to not touch file-backed pages, preventing a deadlock. > + */ > + unsigned int nofs = memalloc_nofs_save(); > + > /* > * Preallocate as many pages as we will need. > */ > @@ -217,6 +227,7 @@ unsigned long page_cache_readahead_limit(struct address_space *mapping, > */ > read_pages(&rac, &page_pool); > BUG_ON(!list_empty(&page_pool)); > + memalloc_nofs_restore(nofs); > return rac.nr_pages; > } > EXPORT_SYMBOL_GPL(page_cache_readahead_limit); -- Michal Hocko SUSE Labs
