Received: by 2002:a05:6a10:6744:0:0:0:0 with SMTP id w4csp4666017pxu; Tue, 13 Oct 2020 04:22:14 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwL6UJFr3oPHWvkHPi1QpnSKyviw150HINvIFaWudev2C4KVBORjKEEdkkw7MsaRiJXOjmD X-Received: by 2002:a17:906:a198:: with SMTP id s24mr31648926ejy.154.1602588134178; Tue, 13 Oct 2020 04:22:14 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1602588134; cv=none; d=google.com; s=arc-20160816; b=MIL4U8PlSXETQVrFNNdGGBCQUPE5rmI/o6VjoBNixdEvxdUbfBPRSbGw+1Q21nkwdG /m/NuuyImxArZsN3bc8h1t/g+drS4ykLloTu7ScFniPLyr1ydTBWYok3P9Rcj1TZp3Mu GHCo+sN2V5Rlv2vRn3L4ILCDG1N4EAe4nbJpbX8t6M916ozNWiT67feei+lEl9HQPf1g faFs2dZ0NjEgKKzWl23SOyCGU4FylUcYsC3oaE00S++aj8kZjUFTcmg6CPVn5pPZIRbo 7R+B6wVkc3Q9Y/lfKm6/V2Zd4nZQNVneIa89tppej49q9nARaCcR2qbJSgk6+Lfl6Jbb 0CcA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:mime-version:user-agent:references:message-id :in-reply-to:subject:cc:to:from:date:dkim-signature; bh=bnow7E0NdAgjP24uVGPtsFmB33v0oAbeU6I6hhEmdgc=; b=wAM0iu9y6o/foDLS/83tYy9UkOKazlClYpjW93cG5xgJ1nFJ3pqVwu64gYkn+psKGx PIXmUethcMkWKlUZ0n5dxq69B/wvuuL853m+P+gBDqSz4KgoACqOdC3v3aua37eawIp+ IJJglICwW4yAlJyL47MVq8uxlbJB1+aUOJoWf9dYwGVkx51B3WD/zC20EHlbJ8dMvZz7 I8wFRJ+ECVrFU8EFL8XrQMHlHUrjU6z403oCN3VCWzvXmDZW2mIZgVAqEFBhF1tiwBaY auvh5p7jpcF0UKpLsd8T48HMhJF3B61KyhybQJ9X2VOKGUEF6gPPQqJ0NH0qm3vSHamb in8A== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b="KrUvpd/N"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id q3si14415951edv.144.2020.10.13.04.21.52; Tue, 13 Oct 2020 04:22:14 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b="KrUvpd/N"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728695AbgJMCaU (ORCPT + 99 others); Mon, 12 Oct 2020 22:30:20 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:37754 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728130AbgJMCaT (ORCPT ); Mon, 12 Oct 2020 22:30:19 -0400 Received: from mail-oi1-x242.google.com (mail-oi1-x242.google.com [IPv6:2607:f8b0:4864:20::242]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 71AA6C0613D0 for ; Mon, 12 Oct 2020 19:30:19 -0700 (PDT) Received: by mail-oi1-x242.google.com with SMTP id s81so8494606oie.13 for ; Mon, 12 Oct 2020 19:30:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=date:from:to:cc:subject:in-reply-to:message-id:references :user-agent:mime-version; bh=bnow7E0NdAgjP24uVGPtsFmB33v0oAbeU6I6hhEmdgc=; b=KrUvpd/NgSTDTdOcGQLuHHaZU0xD55DjswJ8khTx2pSoboXy93Jxf2qHywUyjFDyrL eJQUerC2H2GL4jTguLveYvjUixN4gsg3qBA/m+K5Dfe6h4qUtsz7Vzxttb55XV+X07yB kfJsUhqTIm7vY9XRgP0As0lJu4QCGjFfWbyvTvKwuQN9Ol1pXyvIXfZ0yCe+cDXpIBz0 NktjqctuKy/KaU5U0Jzy7+/tIpw0pkGlOhP2aiJ/dnkqcmgDetRZb/OomuI7G4yUVnsK bQwYA/vsGGaELvLzBIJMzUE0z3E9wAmmRH21fVOl6c2nyipuA/AhCfzP0wGJoCU0LAAQ PArg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:in-reply-to:message-id :references:user-agent:mime-version; bh=bnow7E0NdAgjP24uVGPtsFmB33v0oAbeU6I6hhEmdgc=; b=rV6pAti1r9h9UqzHNKyLo1K0wDIs6q0k1LWm2P+5+1OaeKe32XP4vgwrgQaomqL2XR 0B2iD18KOs4Sc9WTHy4CLTvvY5ngpGr1L0BcEMG2Asb6RaVzfu/xaFf+akl+Ue8fBW0l O3NZ47unWL4RUZdna3V3sXqLTEN57URXcd/aCbfJk4LPhK3Q9rKefXBT+v9GA5h88acK /3e/dghCOg6tMsCiqiOCV4ivGptz0w8S1qpAOzGmP42pKXpnjHJFTH53k2DVtRsp6DGC 37Dblw6rhDubFa81RFcC1NmxAeLfj2JoIgojg9NCnwyxdS3m8Vsg+TNNwliDweDWLsH8 qNfg== X-Gm-Message-State: AOAM5305c2iLTI0Q1rQqcQ82fBTb8I960YgeU7KIl7FSbAQIhAssyqec eLi3QPP3JCl6xcIwUdTNeEDnVg== X-Received: by 2002:aca:c490:: with SMTP id u138mr12541282oif.54.1602556218373; Mon, 12 Oct 2020 19:30:18 -0700 (PDT) Received: from eggly.attlocal.net (172-10-233-147.lightspeed.sntcca.sbcglobal.net. [172.10.233.147]) by smtp.gmail.com with ESMTPSA id x15sm11158198oor.33.2020.10.12.19.30.15 (version=TLS1 cipher=ECDHE-ECDSA-AES128-SHA bits=128/128); Mon, 12 Oct 2020 19:30:17 -0700 (PDT) Date: Mon, 12 Oct 2020 19:30:03 -0700 (PDT) From: Hugh Dickins X-X-Sender: hugh@eggly.anvils To: Andrew Morton cc: Yu Zhao , Hugh Dickins , Michal Hocko , Alex Shi , Steven Rostedt , Ingo Molnar , Johannes Weiner , Vladimir Davydov , Roman Gushchin , Shakeel Butt , Chris Down , Yafang Shao , Vlastimil Babka , Huang Ying , Pankaj Gupta , Matthew Wilcox , Konstantin Khlebnikov , Minchan Kim , Jaewon Kim , cgroups@vger.kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH 00/13] mm: clean up some lru related pieces In-Reply-To: Message-ID: References: <20200918030051.650890-1-yuzhao@google.com> <20200918210126.GA1118730@google.com> User-Agent: Alpine 2.11 (LSU 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, 18 Sep 2020, Hugh Dickins wrote: > On Fri, 18 Sep 2020, Yu Zhao wrote: > > On Fri, Sep 18, 2020 at 01:46:59PM -0700, Hugh Dickins wrote: > > > On Thu, 17 Sep 2020, Yu Zhao wrote: > > > > > > > Hi Andrew, > > > > > > > > I see you have taken this: > > > > mm: use add_page_to_lru_list()/page_lru()/page_off_lru() > > > > Do you mind dropping it? > > > > > > > > Michal asked to do a bit of additional work. So I thought I probably > > > > should create a series to do more cleanups I've been meaning to. > > > > > > > > This series contains the change in the patch above and goes a few > > > > more steps farther. It's intended to improve readability and should > > > > not have any performance impacts. There are minor behavior changes in > > > > terms of debugging and error reporting, which I have all highlighted > > > > in the individual patches. All patches were properly tested on 5.8 > > > > running Chrome OS, with various debug options turned on. > > > > > > > > Michal, > > > > > > > > Do you mind taking a looking at the entire series? > > > > > > > > Thank you. > > > > > > > > Yu Zhao (13): > > > > mm: use add_page_to_lru_list() > > > > mm: use page_off_lru() > > > > mm: move __ClearPageLRU() into page_off_lru() > > > > mm: shuffle lru list addition and deletion functions > > > > mm: don't pass enum lru_list to lru list addition functions > > > > mm: don't pass enum lru_list to trace_mm_lru_insertion() > > > > mm: don't pass enum lru_list to del_page_from_lru_list() > > > > mm: rename page_off_lru() to __clear_page_lru_flags() > > > > mm: inline page_lru_base_type() > > > > mm: VM_BUG_ON lru page flags > > > > mm: inline __update_lru_size() > > > > mm: make lruvec_lru_size() static > > > > mm: enlarge the int parameter of update_lru_size() > > > > > > > > include/linux/memcontrol.h | 14 ++-- > > > > include/linux/mm_inline.h | 115 ++++++++++++++------------------- > > > > include/linux/mmzone.h | 2 - > > > > include/linux/vmstat.h | 2 +- > > > > include/trace/events/pagemap.h | 11 ++-- > > > > mm/compaction.c | 2 +- > > > > mm/memcontrol.c | 10 +-- > > > > mm/mlock.c | 2 +- > > > > mm/swap.c | 53 ++++++--------- > > > > mm/vmscan.c | 28 +++----- > > > > 10 files changed, 95 insertions(+), 144 deletions(-) > > > > > > > > -- > > > > 2.28.0.681.g6f77f65b4e-goog > > > > > > Sorry, Yu, I may be out-of-line in sending this: but as you know, > > > Alex Shi has a long per-memcg lru_lock series playing in much the > > > same area (particularly conflicting in mm/swap.c and mm/vmscan.c): > > > a patchset that makes useful changes, that I'm very keen to help > > > into mmotm a.s.a.p (but not before I've completed diligence). > > > > > > We've put a lot of effort into its testing, I'm currently reviewing > > > it patch by patch (my general silence indicating that I'm busy on that, > > > but slow as ever): so I'm a bit discouraged to have its stability > > > potentially undermined by conflicting cleanups at this stage. > > > > > > If there's general agreement that your cleanups are safe and welcome > > > (Michal's initial reaction sheds some doubt on that), great: I hope > > > that Andrew can fast-track them into mmotm, then Alex rebase on top > > > of them, and I then re-test and re-review. > > > > > > But if that quick agreement is not forthcoming, may I ask you please > > > to hold back, and resend based on top of Alex's next posting? > > > > The per-memcg lru lock series seems a high priority, and I have > > absolutely no problem accommodate your request. > > Many thanks! > > > > > In return, may I ask you or Alex to review this series after you > > have finished with per-memcg lru lock (to make sure that I resolve > > all the conflicts correctly at least)? > > Fair enough: I promise to do so. > > And your rebasing will necessarily lead you to review some parts > of Alex's patchset, which will help us all too. > > Andrew, Yu asked at the start: > > > > I see you have taken this: > > > > mm: use add_page_to_lru_list()/page_lru()/page_off_lru() > > > > Do you mind dropping it? > Dropping that for now will help too. Andrew, please drop Yu Zhao's mm-use-add_page_to_lru_list-page_lru-page_off_lru.patch from the mmotm tree. Yu wants to replace it by this cleanup series, and he has graciously agreed to rebase his series on top of Alex Shi's per-memcg lru_lock series; but mm-use-add_page_to_lru_list-page_lru-page_off_lru.patch is getting in the way of adding them to mmotm. The three of us are all hoping that Alex's v19 series can go into mmotm when the merge window closes, then I'll review Yu's series rebased on top of it. Thanks, Hugh