On Thu 13-02-20 20:27:24, Matthew Wilcox wrote: > On Thu, Feb 13, 2020 at 06:08:24PM +0100, Michal Hocko wrote: > > 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. > > Perhaps even just 'reclaim' -- it's about compaction today, but tomorrow's > VM might try to reclaim these pages too. They are on the LRU, after all. > > So I currently have: > > /* > * 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 reclaim. Telling the VM we're in > * the middle of a filesystem operation will cause it to not > * touch file-backed pages, preventing a deadlock. Most (all?) > * filesystems already specify __GFP_NOFS in their mapping's > * gfp_mask, but let's be explicit here. > */ OK, Thanks! -- Michal Hocko SUSE Labs
