[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200213164607.GR7778@bombadil.infradead.org>
Date: Thu, 13 Feb 2020 08:46:07 -0800
From: Matthew Wilcox <willy@...radead.org>
To: Michal Hocko <mhocko@...nel.org>
Cc: Cong Wang <xiyou.wangcong@...il.com>,
LKML <linux-kernel@...r.kernel.org>,
Andrew Morton <akpm@...ux-foundation.org>,
linux-mm <linux-mm@...ck.org>, Mel Gorman <mgorman@...e.de>,
Vlastimil Babka <vbabka@...e.cz>
Subject: Re: [PATCH] mm: avoid blocking lock_page() in kcompactd
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
+ * 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);
Powered by blists - more mailing lists