From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-11.4 required=3.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_IN_DEF_DKIM_WL autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 10CB7C43465 for ; Fri, 18 Sep 2020 09:36:40 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 6F90321D42 for ; Fri, 18 Sep 2020 09:36:39 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="QxoMVdbJ" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 6F90321D42 Authentication-Results: mail.kernel.org; dmarc=fail (p=reject dis=none) header.from=google.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id E34B76B0055; Fri, 18 Sep 2020 05:36:38 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id DE6708E0001; Fri, 18 Sep 2020 05:36:38 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id CFA886B005C; Fri, 18 Sep 2020 05:36:38 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0058.hostedemail.com [216.40.44.58]) by kanga.kvack.org (Postfix) with ESMTP id B95546B0055 for ; Fri, 18 Sep 2020 05:36:38 -0400 (EDT) Received: from smtpin22.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id 885038249980 for ; Fri, 18 Sep 2020 09:36:38 +0000 (UTC) X-FDA: 77275677276.22.hose84_3b121fd2712a Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin22.hostedemail.com (Postfix) with ESMTP id 6799918038E67 for ; Fri, 18 Sep 2020 09:36:38 +0000 (UTC) X-HE-Tag: hose84_3b121fd2712a X-Filterd-Recvd-Size: 7193 Received: from mail-io1-f67.google.com (mail-io1-f67.google.com [209.85.166.67]) by imf18.hostedemail.com (Postfix) with ESMTP for ; Fri, 18 Sep 2020 09:36:37 +0000 (UTC) Received: by mail-io1-f67.google.com with SMTP id h4so6136785ioe.5 for ; Fri, 18 Sep 2020 02:36:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=ofKvXByFD2eTX9fI7pI8+9B6s6meAkUWiXIy9ZfC+QY=; b=QxoMVdbJPeqrTlkx5f/73dhtxLUkgkyN+VruQyO1/DVhy0/tFaAQ+h9OKo3iWOdoAm //wddD5q8p90+WGg+WpJ94zSSO7WSg8M7myvdhtMW/wPMxjbFaUz/VVwVUtohFRSSNzk 1vP3YbOMqaWT/Y8Qpd4XoChQlpnn/p4KVxLPWfl4+D4iZGVaorta3oTQbrw19jtEzHcO aSM/mYkvKe/uZTa17hL1VogxRTEkxyUKkzzpjeZ8MZk1SbbnJ5s5a0WQmGjIpQMkQNJV +bXdtgXRwCXPz/37ckHEp0MSHu3ks74ZlOBL4iTA1vT8q1rReyNciaVTNptTCYHYonx5 GR3w== 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:message-id:references :mime-version:content-disposition:in-reply-to; bh=ofKvXByFD2eTX9fI7pI8+9B6s6meAkUWiXIy9ZfC+QY=; b=aKMmvBglbssmEfTw3GI2zq4FW9rHjZUftpDaXjDxSOdr+5B6vhtY+3DS2rT0x3qxiJ to2TBTmkZYScdpY6hMYWpoo+c0amz2oTs7b26kQXw1Omhasq/C2PQteDxuJkJBiPhkv3 KBiGdYX+mlAklX70PkvFdsrB+IGA/0jzNKt1pL8X0crKl4WCqjIvy7RJ09lKTZKDzUO9 Lfxi+xwhfGKF+KXSr2WrvRI/lwbUiJJVQjy/2ZPjYHApP/jNxQlSL1Htf0UylfjlRqqb Y5IsHlqxul2XHHxRlz5axex4M0EsBkPSlCFlFRt3YZt3+x/rzDmldbFYqAYNpmSZ9brg O79w== X-Gm-Message-State: AOAM530JEiB6EHaZp/E4fpGIqKy6bBdThvkCWQP29zpe+ibHX9qY6Sb1 gGQJIYlk8/A4jvHXhAnNUcc2pA== X-Google-Smtp-Source: ABdhPJwAlkZO19slkH+E5oDOsW1m+REbN+IIcJ/oxJ2gQ8D4+tsQbVUGfeR7TiaIlDVMQVppOKvA1g== X-Received: by 2002:a6b:590c:: with SMTP id n12mr27341321iob.25.1600421797222; Fri, 18 Sep 2020 02:36:37 -0700 (PDT) Received: from google.com ([2620:15c:183:200:7220:84ff:fe09:2d90]) by smtp.gmail.com with ESMTPSA id x3sm1295974ilq.81.2020.09.18.02.36.35 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 18 Sep 2020 02:36:36 -0700 (PDT) Date: Fri, 18 Sep 2020 03:36:31 -0600 From: Yu Zhao To: Michal Hocko Cc: Andrew Morton , 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 Message-ID: <20200918093631.GA987554@google.com> References: <20200918030051.650890-1-yuzhao@google.com> <20200918074549.GG28827@dhcp22.suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200918074549.GG28827@dhcp22.suse.cz> X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Fri, Sep 18, 2020 at 09:45:49AM +0200, Michal Hocko wrote: > On Thu 17-09-20 21:00:38, 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? > > I have stopped at patch 3 as all patches until then are really missing > any justification. What is the point for all this to be done? The code > is far from trivial and just shifting around sounds like a risk. You are I appreciate your caution, and if you let me know what exactly your concerns are, we could probably work them out together. > removing ~50 LOC which is always nice but I am not sure the resulting > code is better maintainble or easier to read and understand. Just > consider __ClearPageLRU moving to page_off_lru patch. What is the > additional value of having the flag moved and burry it into a function > to have even more side effects? I found the way how __ClearPageLRU is Mind elaborating the side effects? > nicely close to removing it from LRU easier to follow. This is likely > subjective and other might think differently but as it is not clear what > is your actual goal here it is hard to judge pros and cons. I like this specific example from patch 3. Here is what it does: we have three places using the same boilerplate, i.e., page_off_lru() + __ClearPageLRU(), the patch moves __ClearPageLRU() into page_off_lru(), which already does __ClearPageActive() and __ClearPageUnevictable(). Later on, we rename page_off_lru() to __clear_page_lru_flags() (patch 8). Its point seems quite clear to me. Why would *anybody* want to use two helper functions *repeatedly* when the job can be done with just one? Nobody is paid by the number of lines they add, right? :) And for that matter, why would anybody want any boilerplate to be open coded from the same group of helper functions arranged in various ways? I don't think the answer is subjective, but I don't expect everybody to agree with me. Now back to your general question: what's the point of this series? Readability -- less error prone and easier to maintain. This series consolidate open-coded boilerplate like the following in many places. Take lru_lazyfree_fn() as an example: - bool active = PageActive(page); int nr_pages = thp_nr_pages(page); - del_page_from_lru_list(page, lruvec, - LRU_INACTIVE_ANON + active); + del_page_from_lru_list(page, lruvec); ClearPageActive(page); ClearPageReferenced(page); ClearPageSwapBacked(page); - add_page_to_lru_list(page, lruvec, LRU_INACTIVE_FILE); + add_page_to_lru_list(page, lruvec); I hope this helps, but if it doesn't, I'd be more than happy to have more discussions on the details. And not that I don't appreciate your review, but please be more specific than 'sounds like a risk' or 'have even more side effects' so I can address your concerns effectively.