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 Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id B5B91C433F5 for ; Fri, 11 Mar 2022 00:09:36 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 304588D0002; Thu, 10 Mar 2022 19:09:36 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 2B33B8D0001; Thu, 10 Mar 2022 19:09:36 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 17AC28D0002; Thu, 10 Mar 2022 19:09:36 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (relay.hostedemail.com [64.99.140.26]) by kanga.kvack.org (Postfix) with ESMTP id 04F4B8D0001 for ; Thu, 10 Mar 2022 19:09:36 -0500 (EST) Received: from smtpin02.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay12.hostedemail.com (Postfix) with ESMTP id F063F12037B for ; Fri, 11 Mar 2022 00:09:35 +0000 (UTC) X-FDA: 79230171510.02.C4013FE Received: from mail-ua1-f45.google.com (mail-ua1-f45.google.com [209.85.222.45]) by imf22.hostedemail.com (Postfix) with ESMTP id 18E4EC0020 for ; Fri, 11 Mar 2022 00:09:34 +0000 (UTC) Received: by mail-ua1-f45.google.com with SMTP id f23so3064591uam.0 for ; Thu, 10 Mar 2022 16:09:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=KKinXJt7hCI4YpcWmOz6K5DlvGxO13aibVS8plGZoac=; b=HqX+58LeRiyJ+PCpXDzYP5OEeCLu5dtyp+co5T4+ZSilbM/f/SuTyjR/SP5bq59Qje NYcX25WKgHXZ7PNbCD+j6iamM/KYFiq87pv9laSQydiTUaVkWdWBOL8O7VL5I/iQtT9r FDGvPa/3t0WOBLSafpitmkfSrZB3/mW3aphHPPlHNz05DljBZ3DuozCDGJSsvgRkA/W3 AzU1i1dkD4LVMUUI/BLlEVswagAzDBwpK+fmYbh1jYiRkTc7uCVBegSKSNnUzZploBMO wgdVfKk4l0YBvSpGa3nXIddYza4tfmO3p7JqdnzggMQgnms0/2cZUvYp3RRkMrj241nk C7kA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=KKinXJt7hCI4YpcWmOz6K5DlvGxO13aibVS8plGZoac=; b=VBLebHFSDdEP4qjIWt+JPZy20g6gHhhE/gHDzCQPOZYHwXy5E2dY/cJDBONOWeW0rY V/wDjHGfHzSBsXzs9GaertLa+AH61xdUDdnmLmVMpaEOy8lIHaOu6SIOE+vtz7NqIUNK Yxea2mmrdkxIbJ8msMhDEX9sBUIMYwHD+arbEvib0rwJNqBbAalrlg/+TrVxOs8aFV0U +Pto7j0ETR+DLbJ2gOia6mqcj+jmqHhw0USruI83qT0lvnsNllvzq+MiPPGnbuZzYCkP MPq1p+keBPeFt5C8q6pYuVbgodABA5ad4WV6NVINUDOTDYEQZ4xaVGV2zfzneGSPs8h6 9Gvw== X-Gm-Message-State: AOAM531+mH4KES7cJCIzt5zi5Z03CqycHz2tAk2f+C84PpovG+jEPyen 1jK2t32w73WCo3dU/5egzKKJVpVrPHehw6hvRZhbEA== X-Google-Smtp-Source: ABdhPJyb6rTtf+blMbaJtCSG6M567B8/H8bDzy2b/FCzeVtcsifwkglVog4fG17ucBsnOxmlRf+HGHL/HFVCdu14FhY= X-Received: by 2002:ab0:4d52:0:b0:34c:41ce:275b with SMTP id k18-20020ab04d52000000b0034c41ce275bmr3638164uag.19.1646957374015; Thu, 10 Mar 2022 16:09:34 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Yu Zhao Date: Thu, 10 Mar 2022 17:09:22 -0700 Message-ID: Subject: Re: Regression of madvise(MADV_COLD) on shmem? To: Michal Hocko Cc: Minchan Kim , Ivan Teterevkov , Andrew Morton , Linux-MM , linux-kernel , linux-api@vger.kernel.org, Johannes Weiner , Tim Murray , Joel Fernandes , Suren Baghdasaryan , dancol@google.com, Shakeel Butt , sonnyrao@google.com, oleksandr@redhat.com, Hillf Danton , Benoit Lize , Dave Hansen , "Kirill A . Shutemov" Content-Type: text/plain; charset="UTF-8" X-Rspam-User: X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: 18E4EC0020 X-Stat-Signature: hww4eg48dedn9b19rhfcbjs4iw9y1pct Authentication-Results: imf22.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=HqX+58Le; spf=pass (imf22.hostedemail.com: domain of yuzhao@google.com designates 209.85.222.45 as permitted sender) smtp.mailfrom=yuzhao@google.com; dmarc=pass (policy=reject) header.from=google.com X-HE-Tag: 1646957374-801326 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 Thu, Mar 10, 2022 at 2:01 AM Michal Hocko wrote: > > On Mon 07-03-22 13:10:08, Michal Hocko wrote: > > On Sat 05-03-22 02:17:37, Yu Zhao wrote: > > [...] > > > diff --git a/mm/swap.c b/mm/swap.c > > > index bcf3ac288b56..7fd99f037ca7 100644 > > > --- a/mm/swap.c > > > +++ b/mm/swap.c > > > @@ -563,7 +559,7 @@ static void lru_deactivate_file_fn(struct page > > > *page, struct lruvec *lruvec) > > > > > > static void lru_deactivate_fn(struct page *page, struct lruvec *lruvec) > > > { > > > - if (PageActive(page) && !PageUnevictable(page)) { > > > + if (!PageUnevictable(page)) { > > > int nr_pages = thp_nr_pages(page); > > > > > > del_page_from_lru_list(page, lruvec); > > > @@ -677,7 +673,7 @@ void deactivate_file_page(struct page *page) > > > */ > > > void deactivate_page(struct page *page) > > > { > > > - if (PageLRU(page) && PageActive(page) && !PageUnevictable(page)) { > > > + if (PageLRU(page) && !PageUnevictable(page)) { > > > struct pagevec *pvec; > > > > > > local_lock(&lru_pvecs.lock); > > > > > > I'll leave it to Minchan to decide whether this is worth fixing, > > > together with this one: > > > > There doesn't seem to be any dependency on the PageActive anymore. I do > > remember we have relied on the PageActive to move from the active list > > to the inactive. This is not the case anymore but I am wondering whether > > above is really sufficient. If you are deactivating an inactive page > > then I would expect you want to move that page in the LRU as well. In > > other words don't you want > > if (page_active) > > add_page_to_lru_list > > else > > add_page_to_lru_list_tail Yes, this is better. > Do you plan to send an official patch? One thing I still haven't thought through is why the A-bit couldn't protect the blob in the test. In theory it should be enough even though deactivate_page() is a NOP. 1. all pages are initially inactive and have the A-bit set 2. madvise(COLD) clears the A-bit for zero-filled pages (but fails to change their LRU positions) 3. the memcg hits the limit 4. pages in the blob are moved to the active LRU because those pages still have the A-bit (zero-filled pages remain inactive) 5. inactive_is_low() tests true and the blob gets deactivated??? The last step doesn't make sense, since the inactive list is still very large. Thanks.