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 0DDA3C43334 for ; Tue, 7 Jun 2022 18:59:20 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 72DE98D0001; Tue, 7 Jun 2022 14:59:20 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 6DD746B0089; Tue, 7 Jun 2022 14:59:20 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 57DC98D0001; Tue, 7 Jun 2022 14:59:20 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 48B456B0081 for ; Tue, 7 Jun 2022 14:59:20 -0400 (EDT) Received: from smtpin07.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 1EE1D212FC for ; Tue, 7 Jun 2022 18:59:20 +0000 (UTC) X-FDA: 79552352880.07.895AE1C Received: from mail-vs1-f41.google.com (mail-vs1-f41.google.com [209.85.217.41]) by imf10.hostedemail.com (Postfix) with ESMTP id A8EB6C002B for ; Tue, 7 Jun 2022 18:59:19 +0000 (UTC) Received: by mail-vs1-f41.google.com with SMTP id o14so1257787vsv.2 for ; Tue, 07 Jun 2022 11:59:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=9Elzb0WSXIXlROa5Ne/fkFdeuavdNhknMmaOlUejDTY=; b=Cv0f7VDXY7aEPKcXAgnBc/m7gn4KcwOMCSs6PnP0SNIDWWYURJ50n1BCOckHKyAo4L osssjroBU4blBT4uRm44yv1fi6oI2L3ujbMxK0o1i7oGhzuJEZHYVRVpCkNRjU/hFtxf Ifer0vvxCoOUoY1v9kjyMENImilrTTM4fAy0Btq15FrFxyPHCeK2B0D84LFU8iZVCbEM TH8Id7ZOemPx6JqSCTpgYaMPAPVA73HfyKXhphSlNjINHTMX+uRZzLvngc5H22ab9HNY 8jkBwlmf+zLp0DZxf4DQWE1GgEnOF/mife+Vv/Z4dmejaQyeRkI9GPk+3cw2UFYny78M GbTQ== 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=9Elzb0WSXIXlROa5Ne/fkFdeuavdNhknMmaOlUejDTY=; b=cA1xW62aBRan8OX0h62z69CV8dQWMRCQ7AifQOFex1Zp0xAEYW32wKBsX5rIjYf5Zr YH1mQ545ixBwokBvcvS34z7I907o4Y9Hgbv+Yi5gwKki01wvrJBQFgiCmrXZgn1XJ+zC 6DU2dOhOq7mfKULvdpyjJCJuF5zlEckF1EZ/ZIvkcG/mB6WMXiRKSMLBpgO7RrJyUCKH Ud8dpmQQLBlaGaROMGDWfOx/cRL6zkUezjR/9tnTB23dfBTgxCrKdmhHR0oP/usjwrY6 8tOqkzd+Ymm2/bwbBhc/93Lr+ZzPkpue7Og6+j6kr/sx25cjIoyCIdG2YjG+DZG0FDU+ tKUg== X-Gm-Message-State: AOAM5318NqLKiQDA5+mzKe65MMeIt8kn+8hh2bnu8KoDMl0Fm2RS5LpO YFpTu/m3wvh0yUH9+SMzlL0mGXb+gsxBScUHi8VU5g== X-Google-Smtp-Source: ABdhPJwItyNg+JlCejjmtMRo2UgKL6vqnWouemHIBZUAlTzMQTqGRbdROMZliSDf1VNw1QrtZay3uVygVctsRUZw5Ew= X-Received: by 2002:a67:f3d0:0:b0:34b:b52d:d676 with SMTP id j16-20020a67f3d0000000b0034bb52dd676mr6382966vsn.6.1654628358760; Tue, 07 Jun 2022 11:59:18 -0700 (PDT) MIME-Version: 1.0 References: <20220518014632.922072-1-yuzhao@google.com> <20220518014632.922072-8-yuzhao@google.com> In-Reply-To: From: Yu Zhao Date: Tue, 7 Jun 2022 12:58:42 -0600 Message-ID: Subject: Re: [PATCH v11 07/14] mm: multi-gen LRU: exploit locality in rmap To: Barry Song <21cnbao@gmail.com> Cc: 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 , Will Deacon , 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 Content-Type: text/plain; charset="UTF-8" X-Stat-Signature: i8c1jiute3t5es849pqpiw1sotoub3dt Authentication-Results: imf10.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=Cv0f7VDX; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf10.hostedemail.com: domain of yuzhao@google.com designates 209.85.217.41 as permitted sender) smtp.mailfrom=yuzhao@google.com X-Rspam-User: X-Rspamd-Server: rspam11 X-Rspamd-Queue-Id: A8EB6C002B X-HE-Tag: 1654628359-751540 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 Mon, Jun 6, 2022 at 3:25 AM Barry Song <21cnbao@gmail.com> wrote: > > On Wed, May 18, 2022 at 4:49 PM Yu Zhao wrote: ... > > @@ -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? Hi Barry, This is up to individual archs. For x86, ptep_clear_flush_young() is ptep_test_and_clear_young(). For arm64, I'd say yes, based on Figure 1 of Navarro, Juan, et al. "Practical, transparent operating system support for superpages." [1]. int ptep_clear_flush_young(struct vm_area_struct *vma, unsigned long address, pte_t *ptep) { /* * On x86 CPUs, clearing the accessed bit without a TLB flush * doesn't cause data corruption. [ It could cause incorrect * page aging and the (mistaken) reclaim of hot pages, but the * chance of that should be relatively low. ] * * So as a performance optimization don't flush the TLB when * clearing the accessed bit, it will eventually be flushed by * a context switch or a VM operation anyway. [ In the rare * event of it not getting flushed for a long time the delay * shouldn't really matter because there's no real memory * pressure for swapout to react to. ] */ return ptep_test_and_clear_young(vma, address, ptep); } [1] https://www.usenix.org/legacy/events/osdi02/tech/full_papers/navarro/navarro.pdf > is it > safe to call ptep_test_and_clear_young() only? Yes. Though the h/w A-bit is designed to allow OSes to skip TLB flushes when unmapping, the Linux kernel doesn't do this. > btw, lru_gen_look_around() has already included 'address', are we doing > pte check for 'address' twice here? Yes for host MMU but no KVM MMU. ptep_clear_flush_young_notify() goes into the MMU notifier. We don't use the _notify variant in lru_gen_look_around() because GPA space generally exhibits no memory locality. Thanks.