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 0D130C43334 for ; Tue, 7 Jun 2022 10:44:11 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 757756B0072; Tue, 7 Jun 2022 06:44:11 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 7073F6B0075; Tue, 7 Jun 2022 06:44:11 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 5A8D46B0078; Tue, 7 Jun 2022 06:44:11 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 4677C6B0072 for ; Tue, 7 Jun 2022 06:44:11 -0400 (EDT) Received: from smtpin25.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 1E66D21125 for ; Tue, 7 Jun 2022 10:44:11 +0000 (UTC) X-FDA: 79551105102.25.32B92B6 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf21.hostedemail.com (Postfix) with ESMTP id 5DF801C006B for ; Tue, 7 Jun 2022 10:43:54 +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 dfw.source.kernel.org (Postfix) with ESMTPS id 9D38361520; Tue, 7 Jun 2022 10:44:09 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 3CED0C34119; Tue, 7 Jun 2022 10:44:02 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1654598649; bh=nfhDJ6GngF8XvKMVRBe5yZml/Bij47qErsn7ksIcrqE=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=KoHdDKkyuckDx5pSqItebxhU46zBZqhQHomsHausLkCsqN6+q54WWdJzH3Cm0flO0 F9fV0/66aX7znXvR0NEsQjgAfYG+p5crwv/6kA1mJrwFkUmkVjBW5oH/mpIo7EJNRz HUHWRYUCrhF4yi5MWePnMKrO9WnCAZIaWWzZnIF3jVx3ORZ8ZIq0vu5aKuUjmPr8gt EQ2Elys6X55LuWU1ea/ad2e7G0HwJo815xuuNNL2iUjvCOHnWohMG2Y/Ndv6fJMv3M kEgV+yKqmvfiAHExjbwt2ItT6EIkCZEHLJ+yj6SDpPtp8PAr/YzqtciRTJ4OuGeg3N D4MmMCUIZg31w== Date: Tue, 7 Jun 2022 11:43:58 +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: <20220607104358.GA32583@willie-the-truck> References: <20220518014632.922072-1-yuzhao@google.com> <20220518014632.922072-8-yuzhao@google.com> <20220607102135.GA32448@willie-the-truck> 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: 5DF801C006B X-Stat-Signature: sebmqz1dk4eyfje5eby3usmkkp1c7fqh X-Rspam-User: Authentication-Results: imf21.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=KoHdDKky; spf=pass (imf21.hostedemail.com: domain of will@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=will@kernel.org; dmarc=pass (policy=none) header.from=kernel.org X-HE-Tag: 1654598634-675582 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 10:37:46AM +1200, Barry Song wrote: > 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: > > > 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. > > 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? I don't know what this code is doing, so Yu is the best person to answer that. There's nothing inherently dangerous about eliding the TLB maintenance; it really depends on the guarantees needed by the caller. However, the snippet you posted from folio_referenced_one(): | 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, Does seem to call lru_gen_look_around() *and* ptep_clear_flush_young_notify(), which is what prompted my question as it looks pretty suspicious to me. Will