lkml.org 
[lkml]   [2020]   [Feb]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] mm: avoid blocking lock_page() in kcompactd
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

\
 
 \ /
  Last update: 2020-02-14 07:56    [W:0.073 / U:0.568 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site