Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932574AbdCGO1k (ORCPT ); Tue, 7 Mar 2017 09:27:40 -0500 Received: from mail-wr0-f194.google.com ([209.85.128.194]:36728 "EHLO mail-wr0-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755266AbdCGO1J (ORCPT ); Tue, 7 Mar 2017 09:27:09 -0500 Date: Tue, 7 Mar 2017 17:26:43 +0300 From: "Kirill A. Shutemov" To: Minchan Kim Cc: Andrew Morton , kernel-team@lge.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org, Johannes Weiner , Michal Hocko Subject: Re: [RFC 04/11] mm: remove SWAP_MLOCK check for SWAP_SUCCESS in ttu Message-ID: <20170307142643.GD2779@node.shutemov.name> References: <1488436765-32350-1-git-send-email-minchan@kernel.org> <1488436765-32350-5-git-send-email-minchan@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1488436765-32350-5-git-send-email-minchan@kernel.org> User-Agent: Mutt/1.5.23.1 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 998 Lines: 30 On Thu, Mar 02, 2017 at 03:39:18PM +0900, Minchan Kim wrote: > If the page is mapped and rescue in ttuo, page_mapcount(page) == 0 cannot > be true so page_mapcount check in ttu is enough to return SWAP_SUCCESS. > IOW, SWAP_MLOCK check is redundant so remove it. > > Signed-off-by: Minchan Kim > --- > mm/rmap.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/mm/rmap.c b/mm/rmap.c > index 3a14013..0a48958 100644 > --- a/mm/rmap.c > +++ b/mm/rmap.c > @@ -1523,7 +1523,7 @@ int try_to_unmap(struct page *page, enum ttu_flags flags) > else > ret = rmap_walk(page, &rwc); > > - if (ret != SWAP_MLOCK && !page_mapcount(page)) > + if (!page_mapcount(page)) Hm. I think there's bug in current code. It should be !total_mapcount(page) otherwise it can be false-positive if there's THP mapped with PTEs. And in this case ret != SWAP_MLOCK is helpful to cut down some cost. Althouth it should be fine to remove it, I guess. -- Kirill A. Shutemov