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 47304C433EF for ; Tue, 7 Jun 2022 10:38:02 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id C5E186B0072; Tue, 7 Jun 2022 06:38:01 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id C0D5F6B0075; Tue, 7 Jun 2022 06:38:01 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id AD7646B0078; Tue, 7 Jun 2022 06:38:01 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id A14A96B0072 for ; Tue, 7 Jun 2022 06:38:01 -0400 (EDT) Received: from smtpin05.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay12.hostedemail.com (Postfix) with ESMTP id 78534120913 for ; Tue, 7 Jun 2022 10:38:01 +0000 (UTC) X-FDA: 79551089562.05.397C5F0 Received: from mail-ej1-f49.google.com (mail-ej1-f49.google.com [209.85.218.49]) by imf09.hostedemail.com (Postfix) with ESMTP id 0AA85140035 for ; Tue, 7 Jun 2022 10:37:43 +0000 (UTC) Received: by mail-ej1-f49.google.com with SMTP id o7so1003774eja.1 for ; Tue, 07 Jun 2022 03:38:00 -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=WS/YdT6ua32na97CqWFvFSVkMxLLpKjcoq8R6JJDuMg=; b=TfSh23+p1T9WwCPk5m4pQlk64AAbGXFaKssSeb89lrBlH61XMvE7agjozS4le3KPgE eE1vOoqCF7AaTVQN3k826+EK49j/m3GPCkZUSxV7jYuh07XbgEEYYLT3EIzjsR02+2sg qhAdaoiyNuGLlzfGyyB+BBvcz+Kr/dfUbk64LEDzKjKejwj7TIZLmCZiI7mgISfYD6F3 DJUvAhyW0TYYxQ5uXcyFnNC1Mp3pJ2iq2Pm1qBaHk0DD+WPmwORRNVH0JNWq3LfRKHHJ 3c2b57CotnxLsd/CFm55hivT/1ehZlKY17NOY7kbeR4WyXue2Om4pmQMyb6udCpGif9G ksJw== 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=WS/YdT6ua32na97CqWFvFSVkMxLLpKjcoq8R6JJDuMg=; b=T83DvOQCsIIsYa9mFX+zehEqppkK4h3Z183YxO9CXJsbLBauFK96sDTjp0ev51W4IC ztR3TBcvFheQb2eYBtT/zmpe6s5PfwOfdrJa5p/6r1JKCndXy3p0xndThzLcERQj0QLv u+hWZtRDI2xkCCWrOSAQ06CpBe5+9XezNNFtcIkJutf/WuNlWKcbD7txq8qnRAAeT3kC XNYRdeg2HYJZ8oH3hRDP8tgkSqRbgMy7R7yfFAIEP2OhSi17kYm6oIndrqpaMSNtkL+a P6qA6QTCU6TKuFqb4F1KZe4mahlvS0Qp4R3NABSuHWAjaaLGBOuq0PNMRYKvMSTAAd8D E9dA== X-Gm-Message-State: AOAM532L2KE8V3BTC/pf89XYzCWXOd10pIHMKlx9lP/+eAb1c3M1krju WHbR4PBH6hAEyQ31/46RU+EkoyfNGh1ZUtpLfdo= X-Google-Smtp-Source: ABdhPJzS03JWNFZZz5z/idTatyLremjDt75688yaaDyJMkBy/6BjtQbZ6nWd3GG+MYuo4832pvTDkETByAnSxxcSeWM= X-Received: by 2002:a17:907:9715:b0:711:ca06:ca50 with SMTP id jg21-20020a170907971500b00711ca06ca50mr10634070ejc.192.1654598279517; Tue, 07 Jun 2022 03:37:59 -0700 (PDT) MIME-Version: 1.0 References: <20220518014632.922072-1-yuzhao@google.com> <20220518014632.922072-8-yuzhao@google.com> <20220607102135.GA32448@willie-the-truck> In-Reply-To: <20220607102135.GA32448@willie-the-truck> From: Barry Song <21cnbao@gmail.com> Date: Tue, 7 Jun 2022 10:37:46 +1200 Message-ID: Subject: Re: [PATCH v11 07/14] mm: multi-gen LRU: exploit locality in rmap To: Will Deacon Cc: Yu Zhao , Andrew Morton , Linux-MM , Andi Kleen , Aneesh Kumar , Catalin Marinas , Dave Hansen , Hillf Danton , Jens Axboe , Johannes Weiner , Jonathan Corbet , Linus Torvalds , Matthew Wilcox , Mel Gorman , Michael Larabel , Michal Hocko , Mike Rapoport , Peter Zijlstra , Tejun Heo , Vlastimil Babka , LAK , Linux Doc Mailing List , LKML , x86 , Kernel Page Reclaim v2 , 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 , huzhanyuan@oppo.com Content-Type: text/plain; charset="UTF-8" X-Stat-Signature: twe51aiezibdwiyqx9wba3mpdie1dj7z X-Rspam-User: Authentication-Results: imf09.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=TfSh23+p; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf09.hostedemail.com: domain of 21cnbao@gmail.com designates 209.85.218.49 as permitted sender) smtp.mailfrom=21cnbao@gmail.com X-Rspamd-Server: rspam09 X-Rspamd-Queue-Id: 0AA85140035 X-HE-Tag: 1654598263-762464 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 Tue, Jun 7, 2022 at 10:21 PM Will Deacon wrote: > > On Tue, Jun 07, 2022 at 07:37:10PM +1200, Barry Song wrote: > > On Mon, Jun 6, 2022 at 9:25 PM Barry Song <21cnbao@gmail.com> wrote: > > > On Wed, May 18, 2022 at 4:49 PM Yu Zhao wrote: > > > > diff --git a/mm/rmap.c b/mm/rmap.c > > > > index fedb82371efe..7cb7ef29088a 100644 > > > > --- a/mm/rmap.c > > > > +++ b/mm/rmap.c > > > > @@ -73,6 +73,7 @@ > > > > #include > > > > #include > > > > #include > > > > +#include > > > > > > > > #include > > > > > > > > @@ -821,6 +822,12 @@ static bool folio_referenced_one(struct folio *folio, > > > > } > > > > > > > > if (pvmw.pte) { > > > > + if (lru_gen_enabled() && pte_young(*pvmw.pte) && > > > > + !(vma->vm_flags & (VM_SEQ_READ | VM_RAND_READ))) { > > > > + lru_gen_look_around(&pvmw); > > > > + referenced++; > > > > + } > > > > + > > > > if (ptep_clear_flush_young_notify(vma, address, > > > > > > Hello, Yu. > > > look_around() is calling ptep_test_and_clear_young(pvmw->vma, addr, pte + i) > > > only without flush and notify. for flush, there is a tlb operation for arm64: > > > static inline int ptep_clear_flush_young(struct vm_area_struct *vma, > > > unsigned long address, pte_t *ptep) > > > { > > > int young = ptep_test_and_clear_young(vma, address, ptep); > > > > > > if (young) { > > > /* > > > * We can elide the trailing DSB here since the worst that can > > > * happen is that a CPU continues to use the young entry in its > > > * TLB and we mistakenly reclaim the associated page. The > > > * window for such an event is bounded by the next > > > * context-switch, which provides a DSB to complete the TLB > > > * invalidation. > > > */ > > > flush_tlb_page_nosync(vma, address); > > > } > > > > > > return young; > > > } > > > > > > Does it mean the current kernel is over cautious? is it > > > safe to call ptep_test_and_clear_young() only? > > > > I can't really explain why we are getting a random app/java vm crash in monkey > > test by using ptep_test_and_clear_young() only in lru_gen_look_around() on an > > armv8-a machine without hardware PTE young support. > > > > Moving to ptep_clear_flush_young() in look_around can make the random > > hang disappear according to zhanyuan(Cc-ed). > > > > On x86, ptep_clear_flush_young() is exactly ptep_test_and_clear_young() > > after > > 'commit b13b1d2d8692 ("x86/mm: In the PTE swapout page reclaim case clear > > the accessed bit instead of flushing the TLB")' > > > > But on arm64, they are different. according to Will's comments in this > > thread which > > tried to make arm64 same with x86, > > https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1793881.html > > > > " > > This is blindly copied from x86 and isn't true for us: we don't invalidate > > the TLB on context switch. That means our window for keeping the stale > > entries around is potentially much bigger and might not be a great idea. > > > > If we roll a TLB invalidation routine without the trailing DSB, what sort of > > performance does that get you? > > " > > We shouldn't think ptep_clear_flush_young() is safe enough in LRU to > > clear PTE young? Any comments from Will? > > Given that this issue is specific to the multi-gen LRU work, I think Yu is > the best person to comment. However, looking quickly at your analysis above, > I wonder if the code is relying on this sequence: > > > ptep_test_and_clear_young(vma, address, ptep); > ptep_clear_flush_young(vma, address, ptep); > > > to invalidate the TLB. On arm64, that won't be the case, as the invalidation > in ptep_clear_flush_young() is predicated on the pte being young (and this > patches the generic implementation in mm/pgtable-generic.c. In fact, that > second function call is always going to be a no-op unless the pte became > young again in the middle. Hi Will, thanks for your reply, sorry for failing to let you understand my question. my question is actually as below, right now lru_gen_look_around() is using ptep_test_and_clear_young() only without flush to clear pte for a couple of pages including the specific address: void lru_gen_look_around(struct page_vma_mapped_walk *pvmw) { ... for (i = 0, addr = start; addr != end; i++, addr += PAGE_SIZE) { ... if (!ptep_test_and_clear_young(pvmw->vma, addr, pte + i)) continue; ... } I wonder if it is safe to arm64. Do we need to move to ptep_clear_flush_young() in the loop? > > Will Thanks Barry