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 bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 1F1DEC43334 for ; Tue, 7 Jun 2022 10:45:46 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=emBfHz+YG0Ae8s1a4jWBygettJDZn5r+M6l/YdXFoyQ=; b=0D3aX7BA3zddVB efj7OR2g48YXAcCVbhgDkpXJ7U6wNKEBphj6GGFd81ik9BDUlYI+uKZ8kzMjVV//59gXshhv/B3KS r4WGAZ3WiqIGjT1P9hMmhW9312/BAx7898p30a54PNC1QEKTkuzmkW1pzvjzvt9/9fuXeo2uvMf/6 5xZjyGdhBdVsjd+/5gJBkFqr0LvdY6Y3IL5/HzEINE2F0oE7MzCf/QlwneNUBeuBqH7+uft7WU0Bt wLg9QpAVwSxSI8dxxDMc9oiC2u6iEYfGq4PRvodTIFSQ4K6Tdxvn2rMuTEMB9hKguv1IWA4RA2szU tHNCOqIx8QSLIK2j0X0A==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1nyWhI-006m30-WE; Tue, 07 Jun 2022 10:44:29 +0000 Received: from dfw.source.kernel.org ([139.178.84.217]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1nyWh0-006lt0-Bf for linux-arm-kernel@lists.infradead.org; Tue, 07 Jun 2022 10:44:14 +0000 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-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220607_034410_538225_C327DBC5 X-CRM114-Status: GOOD ( 38.05 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org 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 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel