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=-6.8 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI,SIGNED_OFF_BY, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=unavailable 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 428A4C433DF for ; Tue, 26 May 2020 15:56:17 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id CEDDB206F1 for ; Tue, 26 May 2020 15:56:16 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=cmpxchg-org.20150623.gappssmtp.com header.i=@cmpxchg-org.20150623.gappssmtp.com header.b="iuQzFAyi" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org CEDDB206F1 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=cmpxchg.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 60DC1800B6; Tue, 26 May 2020 11:56:16 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 5E31F80010; Tue, 26 May 2020 11:56:16 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 4F96E800B6; Tue, 26 May 2020 11:56:16 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0199.hostedemail.com [216.40.44.199]) by kanga.kvack.org (Postfix) with ESMTP id 3483280010 for ; Tue, 26 May 2020 11:56:16 -0400 (EDT) Received: from smtpin18.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id EA045181AC9C6 for ; Tue, 26 May 2020 15:56:15 +0000 (UTC) X-FDA: 76859321910.18.name02_53b79f9bd342c X-HE-Tag: name02_53b79f9bd342c X-Filterd-Recvd-Size: 6332 Received: from mail-qv1-f67.google.com (mail-qv1-f67.google.com [209.85.219.67]) by imf31.hostedemail.com (Postfix) with ESMTP for ; Tue, 26 May 2020 15:56:14 +0000 (UTC) Received: by mail-qv1-f67.google.com with SMTP id f89so9660924qva.3 for ; Tue, 26 May 2020 08:56:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cmpxchg-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=EUf3sFtG1aKZLccPk3csyFRl/L7Fm5S++ouRqjtAd20=; b=iuQzFAyiPd+zAHIv5I+aA5+rNFzp8NkJtKGGlO2/op7F0/4jDCmrAoukvDW5Q+V0cl DDF5Uc/HiTXImROTvF+k/tMuNJPwbQGfu0vbVls6b1U3jD5rdyqNzo3nb0ny/LnDWJcX r0Lb/NCFI5fQTWYyltkP/vBbCcf6LPn5LVPCvAahhXPFV/JNxYYF4LaeaJ0b9zeyvKAc y95veTnYuESyDEYziLtvLjn19pYDq3Fc8QyxfGRr39aoKhh2sZBaI1jn/+0Ls4NU0RL+ rpEadtuCarQWv0zPV0frCBqZbQO1cUSawMVdcZImBhe0MMp+QRRRQlLa1yHsxOQ98T9l LUTg== 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=EUf3sFtG1aKZLccPk3csyFRl/L7Fm5S++ouRqjtAd20=; b=hS+et36MxpiA7TAJov/FhYghsrYfGyekMT9blmU39kzLn9ALDClfvb7/ccemKNc6lZ 5qXj3a9dK2DqX4uR5NU8nasUu2rDTE8sRZE9QUe9eKGG3+AXFUxsT58jeg868c8xEWEG wjKwBb9HNi9qcrrVGSXnQagcCZHpFa2PlpBNO4gnPGzbFCCinsslouWoGuGbIT7GKjH5 N7y62FQUBvxSYhVmhcLoQRpbPLFe05zniCFkpMXehQXhDf9t6g0UGdF2uhMoMZtWkBvR nC6HorsfwR4ohzxO5ImxjD+tcpFkw2iLMsSNVO7JHOfLqAeenayr9ZYUnzXcvi5w80uA cgMw== X-Gm-Message-State: AOAM532/+g23Xb99mUg3c/JBVPu6XVD0n48RVRIAjTYYHGCfZ8NMTiP5 2TdMft8fFxp6YdJ51ONyEN1kUQ== X-Google-Smtp-Source: ABdhPJyH3g44emP9MQleoe8D8xSlnvtalmliwpMzvo7t/S/m1eVBgBWUtwsZXZ2ODlvswuL4B8PVIw== X-Received: by 2002:ad4:43cc:: with SMTP id o12mr4920294qvs.62.1590508574205; Tue, 26 May 2020 08:56:14 -0700 (PDT) Received: from localhost ([2620:10d:c091:480::1:8152]) by smtp.gmail.com with ESMTPSA id u68sm3894qkf.102.2020.05.26.08.56.12 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 26 May 2020 08:56:13 -0700 (PDT) Date: Tue, 26 May 2020 11:55:49 -0400 From: Johannes Weiner To: Qian Cai Cc: linux-mm@kvack.org, Rik van Riel , Minchan Kim , Michal Hocko , Andrew Morton , Joonsoo Kim , linux-kernel@vger.kernel.org, kernel-team@fb.com Subject: Re: [PATCH 09/14] mm: deactivations shouldn't bias the LRU balance Message-ID: <20200526155549.GB850116@cmpxchg.org> References: <20200520232525.798933-1-hannes@cmpxchg.org> <20200520232525.798933-10-hannes@cmpxchg.org> <20200522133335.GA624@Qians-MacBook-Air.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200522133335.GA624@Qians-MacBook-Air.local> 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, May 22, 2020 at 09:33:35AM -0400, Qian Cai wrote: > On Wed, May 20, 2020 at 07:25:20PM -0400, Johannes Weiner wrote: > > Operations like MADV_FREE, FADV_DONTNEED etc. currently move any > > affected active pages to the inactive list to accelerate their reclaim > > (good) but also steer page reclaim toward that LRU type, or away from > > the other (bad). > > > > The reason why this is undesirable is that such operations are not > > part of the regular page aging cycle, and rather a fluke that doesn't > > say much about the remaining pages on that list; they might all be in > > heavy use, and once the chunk of easy victims has been purged, the VM > > continues to apply elevated pressure on those remaining hot pages. The > > other LRU, meanwhile, might have easily reclaimable pages, and there > > was never a need to steer away from it in the first place. > > > > As the previous patch outlined, we should focus on recording actually > > observed cost to steer the balance rather than speculating about the > > potential value of one LRU list over the other. In that spirit, leave > > explicitely deactivated pages to the LRU algorithm to pick up, and let > > rotations decide which list is the easiest to reclaim. > > > > Signed-off-by: Johannes Weiner > > Acked-by: Minchan Kim > > Acked-by: Michal Hocko > > --- > > mm/swap.c | 4 ---- > > 1 file changed, 4 deletions(-) > > > > diff --git a/mm/swap.c b/mm/swap.c > > index 5d62c5a0c651..d7912bfb597f 100644 > > --- a/mm/swap.c > > +++ b/mm/swap.c > > @@ -515,14 +515,12 @@ static void lru_deactivate_file_fn(struct page *page, struct lruvec *lruvec, > > > > if (active) > > __count_vm_event(PGDEACTIVATE); > > - lru_note_cost(lruvec, !file, hpage_nr_pages(page)); > > } > > > [] > > mm/swap.c: In function 'lru_deactivate_file_fn': > mm/swap.c:504:11: warning: variable 'file' set but not used > [-Wunused-but-set-variable] > int lru, file; > ^~~~ Oops, my gcc doesn't warn about that, but yes, it's clearly dead code. $ make mm/swap.o GEN Makefile CALL /home/hannes/src/linux/linux/scripts/checksyscalls.sh CALL /home/hannes/src/linux/linux/scripts/atomic/check-atomics.sh DESCEND objtool CC mm/swap.o $ > This? > > diff --git a/mm/swap.c b/mm/swap.c > index fedf5847dfdb..9c38c1b545af 100644 > --- a/mm/swap.c > +++ b/mm/swap.c > @@ -501,7 +501,7 @@ void lru_cache_add_active_or_unevictable(struct page *page, > static void lru_deactivate_file_fn(struct page *page, struct lruvec *lruvec, > void *arg) > { > - int lru, file; > + int lru; > bool active; > > if (!PageLRU(page)) > @@ -515,7 +515,6 @@ static void lru_deactivate_file_fn(struct page *page, struct lruvec *lruvec, > return; > > active = PageActive(page); > - file = page_is_file_lru(page); > lru = page_lru_base_type(page); > > del_page_from_lru_list(page, lruvec, lru + active); Looks good, and it appears Andrew has already queued it. Would you mind providing the Signed-off-by: for it?