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 CD0E1C433EF for ; Thu, 24 Mar 2022 08:14:05 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id E46488D0005; Thu, 24 Mar 2022 04:14:04 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id DF5E38D0003; Thu, 24 Mar 2022 04:14:04 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C976D8D0005; Thu, 24 Mar 2022 04:14:04 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0084.hostedemail.com [216.40.44.84]) by kanga.kvack.org (Postfix) with ESMTP id B705A8D0003 for ; Thu, 24 Mar 2022 04:14:04 -0400 (EDT) Received: from smtpin18.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id 66B608249980 for ; Thu, 24 Mar 2022 08:14:04 +0000 (UTC) X-FDA: 79278566808.18.358E307 Received: from mail-ed1-f41.google.com (mail-ed1-f41.google.com [209.85.208.41]) by imf06.hostedemail.com (Postfix) with ESMTP id DB90E180007 for ; Thu, 24 Mar 2022 08:14:03 +0000 (UTC) Received: by mail-ed1-f41.google.com with SMTP id r23so4718858edb.0 for ; Thu, 24 Mar 2022 01:14:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=etzSqv0/9aE5pl3dptR4Y8mgC5YpOiktHoANWy6nVdw=; b=Hc7dpeqOaV8CbCzshfeBcroqqi9BWzXZNnC75s6jVj4ou7A/Az8JJZcWxp9eXEaPJ2 DLQecJ3yjC64JAw39a3YrNXqEFckso4ovxJ0+w5xoMWAE+2H+O07V6akUaLfbRNNmIQg H2J1URluwCxdDV05AQ5GAkvCo71xyKd3D21tTUK87RVYfmG7CVBtdGOwXYDrgu+m3sJU iEkbSMfx2q3Py7p1y3ieK7GpQao70xTEEzmoUDttUWEq744IaIc/w6DCFylRiV3u2BsC QtVEwXhrqauOPnOsrmMmE8mKu0GmUa3pfGX8cUlIJBBbjJfAoWXIuyUNWAwxTLB+UjnA Dx6A== 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=etzSqv0/9aE5pl3dptR4Y8mgC5YpOiktHoANWy6nVdw=; b=WElHXoHRTZdR9l9hD0Kud6J7qCNUSx8StYL4hnKJvsX1mL7ocUWHqi1Mp7pyhJUMhT EuNJ/TNjDqBtV2kJRH4n+WMf6bs9RSaaDxczJUg2SjkzMFgcy9KQNEbkgcmkNA6HVoA4 2/6WSrlslEQUxy+LqJGBRah4+4XsijEDkhz88nHHJ3DZCn4qdYhuD/0eXFnYbCfeQ+PQ CBJ3nsNql8atJKt3CKftGLaY4jwYUcph7W1t15vDAQh1jsVxLDi0U1o/K5fVK/s5fJfM cbTP9wwGbGtNbXsYXbnFsffk1UoQFrv0OPd4HRv2T3N9sYYQRDboAYuGnTu9tBkRRedN P20g== X-Gm-Message-State: AOAM532ewEWnuS0WZLl5L2gj13qZMu07I3Ogw8CSotAAeaPnfvhbdep5 FPRevOtuNyRKtrF6yxsfviLekzv7w5LslOoS1rY= X-Google-Smtp-Source: ABdhPJxB9yM2gtllAWM/wn6zYLnJI+r0tWFlQ5gSs9AFZo0W3max2hZtxlTeTG9Es8ssycmuut12zhjOu6WdRn5durE= X-Received: by 2002:a50:fe0d:0:b0:415:e2ee:65af with SMTP id f13-20020a50fe0d000000b00415e2ee65afmr5075480edt.383.1648109642312; Thu, 24 Mar 2022 01:14:02 -0700 (PDT) MIME-Version: 1.0 References: <20220309021230.721028-1-yuzhao@google.com> <20220309021230.721028-7-yuzhao@google.com> In-Reply-To: From: Barry Song <21cnbao@gmail.com> Date: Thu, 24 Mar 2022 21:13:48 +1300 Message-ID: Subject: Re: [PATCH v9 06/14] mm: multi-gen LRU: minimal implementation To: Yu Zhao Cc: Andrew Morton , Linus Torvalds , Andi Kleen , Aneesh Kumar , Catalin Marinas , Dave Hansen , Hillf Danton , Jens Axboe , Jesse Barnes , Johannes Weiner , Jonathan Corbet , Matthew Wilcox , Mel Gorman , Michael Larabel , Michal Hocko , Mike Rapoport , Rik van Riel , Vlastimil Babka , Will Deacon , Ying Huang , LAK , Linux Doc Mailing List , LKML , Linux-MM , Kernel Page Reclaim v2 , x86 , Brian Geffon , Jan Alexander Steffens , Oleksandr Natalenko , Steven Barrett , Suleiman Souhlal , Daniel Byrne , Donald Carr , =?UTF-8?Q?Holger_Hoffst=C3=A4tte?= , Konstantin Kharlamov , Shuang Zhai , Sofia Trinh , Vaibhav Jain Content-Type: text/plain; charset="UTF-8" Authentication-Results: imf06.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=Hc7dpeqO; spf=pass (imf06.hostedemail.com: domain of 21cnbao@gmail.com designates 209.85.208.41 as permitted sender) smtp.mailfrom=21cnbao@gmail.com; dmarc=pass (policy=none) header.from=gmail.com X-Rspam-User: X-Rspamd-Server: rspam10 X-Rspamd-Queue-Id: DB90E180007 X-Stat-Signature: ka1t8dfz5qmbad888wnt7xwrk1inws71 X-HE-Tag: 1648109643-15593 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 24, 2022 at 7:24 PM Yu Zhao wrote: > > On Wed, Mar 23, 2022 at 1:47 AM Barry Song <21cnbao@gmail.com> wrote: > > > > On Sat, Mar 19, 2022 at 4:11 PM Yu Zhao wrote: > > > > > > On Fri, Mar 18, 2022 at 9:01 PM Barry Song <21cnbao@gmail.com> wrote: > > > > > > > > > +static int folio_inc_gen(struct lruvec *lruvec, struct folio *folio, bool reclaiming) > > > > > +{ > > > > > + unsigned long old_flags, new_flags; > > > > > + int type = folio_is_file_lru(folio); > > > > > + struct lru_gen_struct *lrugen = &lruvec->lrugen; > > > > > + int new_gen, old_gen = lru_gen_from_seq(lrugen->min_seq[type]); > > > > > + > > > > > + do { > > > > > + new_flags = old_flags = READ_ONCE(folio->flags); > > > > > + VM_BUG_ON_FOLIO(!(new_flags & LRU_GEN_MASK), folio); > > > > > + > > > > > + new_gen = ((new_flags & LRU_GEN_MASK) >> LRU_GEN_PGOFF) - 1; > > > > > + new_gen = (old_gen + 1) % MAX_NR_GENS; > > > > > > > > new_gen is assigned twice, i assume you mean > > > > old_gen = ((new_flags & LRU_GEN_MASK) >> LRU_GEN_PGOFF) - 1; > > > > new_gen = (old_gen + 1) % MAX_NR_GENS; > > > > > > > > or do you always mean new_gen = lru_gen_from_seq(min_seq) + 1? > > > > > > Thanks a lot for your attention to details! > > > > > > The first line should be in the next patch but I overlooked during the > > > last refactoring: > > > > Thanks for the clarification. So an unmapped file-backed page which is > > accessed only by system call will always be in either min_seq or > > min_seq + 1? it has no chance to be in max_seq like a faulted-in > > mapped file page? > > That's right. The rationale is documented here under the `Assumptions` > section [1]. This is also related to Aneesh's question about why MGLRU > doesn't need additional heuristics for VM_EXEC pages [2]. Unmapped > file pages weaken the protection of executable pages under heavy > buffered IO workloads like Java NIO. ok. This is probably right. i will also run a test by maltreating unmapped page in vanilla LRU, the PoC code is like (not been tested yet): Subject: [PATCH 1/1] mm: vmscan: maltreat unmapped file-backed pages [This patch has not been tested yet.] A lesson we learned from MGLRU is that mapped filed-backed pages are much more important than unmapped ones. So this patch doesn't move the second accessed unmapped pages to the active list, alternatively, it keeps the pages in the inactive list. And we abuse PG_workingset to let the memory reclaim this is a relatively hot file-backed page, so the reclaim should keep the pages in the inactive list. --- mm/swap.c | 34 ++++++++++++++++++++++------------ mm/vmscan.c | 6 ++++-- 2 files changed, 26 insertions(+), 14 deletions(-) diff --git a/mm/swap.c b/mm/swap.c index e65e7520bebf..cb0c6e704f2e 100644 --- a/mm/swap.c +++ b/mm/swap.c @@ -470,18 +470,28 @@ void folio_mark_accessed(struct folio *folio) * evictable page accessed has no effect. */ } else if (!folio_test_active(folio)) { - /* - * If the page is on the LRU, queue it for activation via - * lru_pvecs.activate_page. Otherwise, assume the page is on a - * pagevec, mark it active and it'll be moved to the active - * LRU on the next drain. - */ - if (folio_test_lru(folio)) - folio_activate(folio); - else - __lru_cache_activate_folio(folio); - folio_clear_referenced(folio); - workingset_activation(folio); + if (folio_mapped(folio)) { + /* + * If the mapped page is on the LRU, queue it for activation via + * lru_pvecs.activate_page. Otherwise, assume the page is on a + * pagevec, mark it active and it'll be moved to the active + * LRU on the next drain. + */ + if (folio_test_lru(folio)) + folio_activate(folio); + else + __lru_cache_activate_folio(folio); + folio_clear_referenced(folio); + workingset_activation(folio); + } else { + /* + * we maltreat unmmaped file-backed pages and abuse PG_workingset + * flag to let the eviction know this page is a relatively hot file + * page, thus, the eviction can move it back to the head of the + * inactive list + */ + folio_set_workingset(folio); + } } if (folio_test_idle(folio)) folio_clear_idle(folio); diff --git a/mm/vmscan.c b/mm/vmscan.c index d6f3c9812f97..56a66eb4a3f7 100644 --- a/mm/vmscan.c +++ b/mm/vmscan.c @@ -1393,12 +1393,14 @@ enum page_references { static enum page_references page_check_references(struct page *page, struct scan_control *sc) { - int referenced_ptes, referenced_page; + int referenced_ptes, referenced_page, workingset; unsigned long vm_flags; referenced_ptes = page_referenced(page, 1, sc->target_mem_cgroup, &vm_flags); referenced_page = TestClearPageReferenced(page); + workingset = page_is_file_lru(page) && !page_mapped(page) && + TestClearPageWorkingset(page); /* * Mlock lost the isolation race with us. Let try_to_unmap() @@ -1438,7 +1440,7 @@ static enum page_references page_check_references(struct page *page, /* Reclaim if clean, defer dirty pages to writeback */ if (referenced_page && !PageSwapBacked(page)) - return PAGEREF_RECLAIM_CLEAN; + return workingset ? PAGEREF_KEEP : PAGEREF_RECLAIM_CLEAN; return PAGEREF_RECLAIM; } > > [1] https://lore.kernel.org/linux-mm/20220309021230.721028-15-yuzhao@google.com/ > [2] https://lore.kernel.org/linux-mm/CAOUHufYfpiGdLSdffvzDqaD5oYFG99oDJ2xgQd2Ph77OFR5NAA@mail.gmail.com/ Thanks Barry