Received: by 2002:a05:6a10:f347:0:0:0:0 with SMTP id d7csp2999356pxu; Tue, 8 Dec 2020 00:18:51 -0800 (PST) X-Google-Smtp-Source: ABdhPJy++5Hpx3gOa2J6nhodtWsM0x45NoX80+1BDGBejG18diDjQT/9Jmna1g0x7LioMNdF06kV X-Received: by 2002:a17:906:a182:: with SMTP id s2mr21392692ejy.249.1607415531415; Tue, 08 Dec 2020 00:18:51 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1607415531; cv=none; d=google.com; s=arc-20160816; b=eIafRVc92eS1DImd7te2SYzCkyX4cDLwuQx02RS4EjO7JQdmsmwMgMaSJOknI6jEq5 nbBxFSKMOrB9ndw0WZzZLmG+rEDDNxpFsAGIT9zOtZdBb6W9eD5k3c+GjjK2YbBMLD1c BvooUUz/Ei0x8TWooPML1XOC9Lf/Ym3VCpi28jzK7E3/0qF9vD4KUmRYeL5AUY4Ds4AO Yqpaa3OwmQ2wg2V/aCb52n2vVU2Z+5yo/QJF6ZpoNntDcw1R0qnMA2SiWCsuOsGfIqD5 1IwKStYhQaiqmTn4PkYOOMa3TQtar0S6WjowANx4cEYtfLrRt5p2UtBtowx+CHb2fU8A /a6g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:in-reply-to :mime-version:user-agent:date:message-id:from:references:cc:to :subject; bh=Sc2+oSOydlIG8TTGGqnSXXJkKSMlMtV0d187rk97uGg=; b=FXYjQ8OmKiadbbyCkEhVdBR+fT+bYqCLl0pJk9PeXLuO3MzPbVj+geN8RK+ib3ysnX wqirij9/praDqfM0DUGi+3P6y4wnQiPnh//dE9v/CbC4oPOHL32kXp7837HIZb56b2rI UeucXYCudFfJ61KNO8C0NM1+V8SdLWUy6WBcQ92lAsZ/OiOPExPWgDbHcxZdFMOebYtY BWzerIdSlGNrBK+7EWjGuDW0z3pdtpVW3ubwNpAwGFrIrJemhpIpsLXxv6I/k5bdzxrs icRpaKpUuRJtirB+Ozk5Doldp3Kov/mqzJ5j9qUTEHoQjth0nNfliaD6x42aWiHj8rJL bjyQ== ARC-Authentication-Results: i=1; mx.google.com; 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=fail (p=NONE sp=NONE dis=NONE) header.from=alibaba.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id j26si10065500eds.457.2020.12.08.00.18.28; Tue, 08 Dec 2020 00:18:51 -0800 (PST) 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; 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=fail (p=NONE sp=NONE dis=NONE) header.from=alibaba.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728078AbgLHIPq (ORCPT + 99 others); Tue, 8 Dec 2020 03:15:46 -0500 Received: from out30-133.freemail.mail.aliyun.com ([115.124.30.133]:35730 "EHLO out30-133.freemail.mail.aliyun.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727135AbgLHIPq (ORCPT ); Tue, 8 Dec 2020 03:15:46 -0500 X-Alimail-AntiSpam: AC=PASS;BC=-1|-1;BR=01201311R191e4;CH=green;DM=||false|;DS=||;FP=0|-1|-1|-1|0|-1|-1|-1;HT=e01e04407;MF=alex.shi@linux.alibaba.com;NM=1;PH=DS;RN=11;SR=0;TI=SMTPD_---0UHy7DrU_1607415299; Received: from IT-FVFX43SYHV2H.local(mailfrom:alex.shi@linux.alibaba.com fp:SMTPD_---0UHy7DrU_1607415299) by smtp.aliyun-inc.com(127.0.0.1); Tue, 08 Dec 2020 16:14:59 +0800 Subject: Re: [PATCH 03/11] mm: don't pass "enum lru_list" to lru list addition functions To: Yu Zhao , Andrew Morton , Hugh Dickins Cc: Michal Hocko , Johannes Weiner , Vladimir Davydov , Roman Gushchin , Vlastimil Babka , Matthew Wilcox , linux-mm@kvack.org, linux-kernel@vger.kernel.org References: <20201207220949.830352-1-yuzhao@google.com> <20201207220949.830352-4-yuzhao@google.com> From: Alex Shi Message-ID: <444fa3b9-2263-4f0a-3ff3-beaf2472f23f@linux.alibaba.com> Date: Tue, 8 Dec 2020 16:14:58 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 MIME-Version: 1.0 In-Reply-To: <20201207220949.830352-4-yuzhao@google.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 在 2020/12/8 上午6:09, Yu Zhao 写道: > > __count_vm_events(PGACTIVATE, nr_pages); > @@ -543,14 +542,14 @@ static void lru_deactivate_file_fn(struct page *page, struct lruvec *lruvec) > * It can make readahead confusing. But race window > * is _really_ small and it's non-critical problem. > */ > - add_page_to_lru_list(page, lruvec, lru); > + add_page_to_lru_list(page, lruvec); > SetPageReclaim(page); > } else { > /* > * The page's writeback ends up during pagevec > * We moves tha page into tail of inactive. > */ > - add_page_to_lru_list_tail(page, lruvec, lru); > + add_page_to_lru_list_tail(page, lruvec); > __count_vm_events(PGROTATED, nr_pages); > } > > @@ -570,7 +569,7 @@ static void lru_deactivate_fn(struct page *page, struct lruvec *lruvec) > del_page_from_lru_list(page, lruvec, lru + LRU_ACTIVE); > ClearPageActive(page); > ClearPageReferenced(page); > - add_page_to_lru_list(page, lruvec, lru); > + add_page_to_lru_list(page, lruvec); > > __count_vm_events(PGDEACTIVATE, nr_pages); > __count_memcg_events(lruvec_memcg(lruvec), PGDEACTIVATE, seems leave the lru = xxx out, could save 2 function calling in lru_deactivate_file_fn(), is this right?