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 EE832C433EF for ; Tue, 7 Jun 2022 10:21:51 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id F3E768D0001; Tue, 7 Jun 2022 06:21:50 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id F14B76B007E; Tue, 7 Jun 2022 06:21:50 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id DDD818D0001; Tue, 7 Jun 2022 06:21:50 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id CB4DE6B007D for ; Tue, 7 Jun 2022 06:21:50 -0400 (EDT) Received: from smtpin23.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay13.hostedemail.com (Postfix) with ESMTP id 91E1360C2B for ; Tue, 7 Jun 2022 10:21:50 +0000 (UTC) X-FDA: 79551048780.23.424E5C6 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by imf25.hostedemail.com (Postfix) with ESMTP id EDE58A0003 for ; Tue, 7 Jun 2022 10:21:10 +0000 (UTC) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id BDD1EB81E75; Tue, 7 Jun 2022 10:21:47 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 99FB4C34115; Tue, 7 Jun 2022 10:21:39 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1654597306; bh=ERNPm8lNz6G7He3QqXaKBpkXFAN043C4YtKDX4d0tlU=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=AgqUUyVx3DL0GR3U/MsHK/+4nuGnyVvrJrFwX+u9O6T/KpYcSv+mbQFH71PSfga5E sOkaqv+OnCz4aBxxNjAeUaCXjt807P1V6EtX0bsn4dbTGdrIcONODyYLoAM+9JEPTX RQwPrgPnPsu2rVz2kWRhnWSBFQUbfsYxbsLzEVu0j/WCDEqiI0q6D7m8GcWXgklPUf q7dtfevVd3RjtowMBSWbciPODQ8CqjjkMfMmlWd6Pl3+j6J2v2VKiOZvijl46oPhEP U3AW1p0kIalQvY80qEUdqjYveymWlt7IFeorkIlCi2eHojjlcAGJRVdzzP8DfKh9zP YbbfjeYplA05Q== Date: Tue, 7 Jun 2022 11:21:35 +0100 From: Will Deacon To: Barry Song <21cnbao@gmail.com> 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 , Holger =?iso-8859-1?Q?Hoffst=E4tte?= , Konstantin Kharlamov , Shuang Zhai , Sofia Trinh , Vaibhav Jain , huzhanyuan@oppo.com Subject: Re: [PATCH v11 07/14] mm: multi-gen LRU: exploit locality in rmap Message-ID: <20220607102135.GA32448@willie-the-truck> References: <20220518014632.922072-1-yuzhao@google.com> <20220518014632.922072-8-yuzhao@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: EDE58A0003 X-Stat-Signature: wadp4mh8m8ufh46awmdd6fbytgx5xxth X-Rspam-User: Authentication-Results: imf25.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=AgqUUyVx; spf=pass (imf25.hostedemail.com: domain of will@kernel.org designates 145.40.68.75 as permitted sender) smtp.mailfrom=will@kernel.org; dmarc=pass (policy=none) header.from=kernel.org X-HE-Tag: 1654597270-831746 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 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. Will