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 33946C43334 for ; Tue, 7 Jun 2022 10:29:51 +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=z5sgtDvbDjDgrkiTj+kwMBtWISlHJg7BfeowIA7+VuQ=; b=ml310Wx4TJLHFY BiZ9WIXtFqm/yDzL3oISI2xelAJ5fvYJmas1Jt13ctAWOdhjmN441AmxxtAEMyErZD9zLmmoTROVg AvYpyoOk56hfiTjSbQ4iXi0tOH2rTklL+s6Y4nUstmHEqdNMTzK+iHzJYIcKCAniUvrfX/DJnAlPH vpLJy1Cc22MAlqQH6G5SED49ET9Yq+v6PZJubPa9Wp5EvzzcSSblhZ33o8yChY8aRHsJ56DPTTsyL 1BbIrkKjbHimnG1RIQWkWPVMFM9DZj4XtXrnUJ3bVtlGRzmFqz6497MUYFf1l5SCmhVbdapusWzVY UBuohLEGbdI18JfZ80vQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1nyWRk-006eQy-T9; Tue, 07 Jun 2022 10:28:25 +0000 Received: from ams.source.kernel.org ([145.40.68.75]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1nyWLN-006bdr-Gy for linux-arm-kernel@lists.infradead.org; Tue, 07 Jun 2022 10:21:51 +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 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-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_032149_897088_D36C4C04 X-CRM114-Status: GOOD ( 37.86 ) 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 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 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel