[Top] [All Lists]

Re: [PATCH] mm: fix direct reclaim writeback regression

To: Vlastimil Babka <vbabka@xxxxxxx>
Subject: Re: [PATCH] mm: fix direct reclaim writeback regression
From: Hugh Dickins <hughd@xxxxxxxxxx>
Date: Sat, 26 Jul 2014 16:15:25 -0700 (PDT)
Cc: Hugh Dickins <hughd@xxxxxxxxxx>, Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx>, Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>, David Rientjes <rientjes@xxxxxxxxxx>, Rik van Riel <riel@xxxxxxxxxx>, Johannes Weiner <hannes@xxxxxxxxxxx>, Dave Jones <davej@xxxxxxxxxx>, Dave Chinner <david@xxxxxxxxxxxxx>, xfs@xxxxxxxxxxx, linux-kernel@xxxxxxxxxxxxxxx, linux-mm@xxxxxxxxx
Delivered-to: xfs@xxxxxxxxxxx
Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=date:from:to:cc:subject:in-reply-to:message-id:references :user-agent:mime-version:content-type; bh=9+6+7ZmR66Engdfrc/P3JrqPXq0lvjB+MRfiUeeSx7w=; b=iLa2TnAsEmIOwY3QRYKZwqK7bZ+Wpz5VQGFARJhOwpn61HkHodTpP+kogYcj5DSGpq dTbrDz0J2yf1Nx7ioK5npC8BkpzyLhT/ZbM2pdbajXrrIoQI9pOrdpO1pFS0bosxjnPj pFHDWGLmSNwNCv7eA9o2+nPBTArgh3pyUZqNuWQCQXRfKkmRhJNKd0i2FoZinj5gUaX3 krw47WS6gLSysfOh0sVvHMeHh5lTICN7ZJ4hZVo5gK9+CO+lXSXIZXtlNz+szHtE/Ssi ok7RMk2nBBsjbbQ/FEKw5CjcjwoiTdyW8GBYkwvX6Bbv7sQAwrol8EwAyUn6sQA3yEBQ zMCQ==
In-reply-to: <53D42F80.7000000@xxxxxxx>
References: <alpine.LSU.2.11.1407261248140.13796@xxxxxxxxxxxx> <53D42F80.7000000@xxxxxxx>
User-agent: Alpine 2.11 (LSU 23 2013-08-11)
On Sun, 27 Jul 2014, Vlastimil Babka wrote:
> On 07/26/2014 09:58 PM, Hugh Dickins wrote:
> > Yes, 3.16-rc1's 68711a746345 ("mm, migration: add destination page
> > freeing callback") has provided such a way to compaction: if migrating
> > a SwapBacked page fails, its newpage may be put back on the list for
> > later use with PageSwapBacked still set, and nothing will clear it.
> Ugh good catch. So is this the only flag that can become "stray" like
> this? It seems so from quick check...

Yes, it seemed so to me too; but I would prefer a regime in which
we only mess with newpage once it's sure to be successful.

> > --- 3.16-rc6/mm/migrate.c   2014-06-29 15:22:10.584003935 -0700
> > +++ linux/mm/migrate.c      2014-07-26 11:28:34.488126591 -0700
> > @@ -988,9 +988,10 @@ out:
> >      * it.  Otherwise, putback_lru_page() will drop the reference grabbed
> >      * during isolation.
> >      */
> > -   if (rc != MIGRATEPAGE_SUCCESS && put_new_page)
> > +   if (rc != MIGRATEPAGE_SUCCESS && put_new_page) {
> > +           ClearPageSwapBacked(newpage);
> >             put_new_page(newpage, private);
> > -   else
> > +   } else
> >             putback_lru_page(newpage);
> >  
> >     if (result) {
> What about unmap_and_move_huge_page()? Seems to me it can also get the
> same stray flag. Although compaction, who is the only user so far of
> custom put_new_page, wouldn't of course migrate huge pages. But might
> bite us in the future, if a new user appears before a cleanup...

I think you're right, thanks for pointing it out.  We don't have an
actual bug there at present, so no need to rush back and fix up the
patch now in Linus's tree; but unmap_and_move_huge_page() gives
another reason why my choice was "probably the worst place to fix it".

More reason for a cleanup, but not while the memcg interface is in flux.
In mmotm I'm a little anxious about the PageAnon case when newpage's
mapping is left set, I wonder if that might also be problematic: I
mailed Hannes privately to think about that - perhaps that will give
more impulse for a cleanup, though I've not noticed any bug from it.


<Prev in Thread] Current Thread [Next in Thread>