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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 8BC6DC433FE for ; Wed, 27 Apr 2022 06:01:29 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1357945AbiD0GEh (ORCPT ); Wed, 27 Apr 2022 02:04:37 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:45940 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S242834AbiD0GEf (ORCPT ); Wed, 27 Apr 2022 02:04:35 -0400 Received: from mail-ua1-x92f.google.com (mail-ua1-x92f.google.com [IPv6:2607:f8b0:4864:20::92f]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 187F73FDBC for ; Tue, 26 Apr 2022 23:01:25 -0700 (PDT) Received: by mail-ua1-x92f.google.com with SMTP id 63so241372uaw.10 for ; Tue, 26 Apr 2022 23:01:25 -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=eEenBPTT+A8NftOZwlTNAzvJdJr06gaMpQKvN58cBsM=; b=rB0CdeG5tjzYHEixLfnyBxBN8Py8g9fJZ/W8h2JVMHNdvkQi0/EHFiqOmCaacpuXFU 628XUqXPgbnn7+t5QuJUsrZg0LS0BjRpKvOscPq6mLwMsr41GQdTFZiIRZmRxLrzsb7t uvwjkz4lksY9DHaFI2FD37wIh3fNKYVnM/qZpX2u6qfDLcCGqIpzO7YPwg8nfDpIxdJH dm14+oFOJdwhUJoom7iHvraVdDFnJTXC3IshjVIwoqTpyXHZno4TMfXJ9p98ndxMp3bU 5WMIyH8nXzVUxgIPlTZ4F3VnO56QrYBo2felfbpX4PnzYDfDjf311D8Hgg8LcOQygVEK qH0g== 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=eEenBPTT+A8NftOZwlTNAzvJdJr06gaMpQKvN58cBsM=; b=YzIjkMSgOwaGhHbkVw/3+jE8LYbmKiE60Q/A7L5b2MODdWnTew6ZpVmD8SVwAygYc+ 7D8Gm7MpXYZbbd50ieAEJA0sigtuAnNBCTbqxdRt5YdWbouPCfBgoTgRZEVOVwiixRD1 lbGrRKi5l/w/o9fyjPXXAMZrJ3JWDnXhhUNbWLonqm3LSEl9GfwilGN7ACBJBkTQwOg0 1ax6IABatSrWp21IbWHuOd1FUKVwJO+RCo8krH7eLNYTNx+xHPY93lo0CP+QD1Yum0FN UvL5lZRdsPBUCQua4GpEbe7gTNCy2UDN6H0fh50WYXGaXS3AV32USyx7SGmGbKw3fPDq fqxA== X-Gm-Message-State: AOAM532jE99JDrcGHTMoi3FribdE3mBeM0MHOwKIOOUi71WRp5i2MusB 2FLykQeV2gRPchvkcrwVvmXmWpbPMU3SNG4zSmbUnA== X-Google-Smtp-Source: ABdhPJxgvGijbH7jxYuaIKjHR/e2sUn7feZnfqFOoKQXZ9QvO1ndFMrJOawwmWogeWkH02N9ILsUauEjnILfGArW+Qs= X-Received: by 2002:ab0:77d5:0:b0:352:42d7:88c2 with SMTP id y21-20020ab077d5000000b0035242d788c2mr7891618uar.1.1651039283985; Tue, 26 Apr 2022 23:01:23 -0700 (PDT) MIME-Version: 1.0 References: <20220407031525.2368067-1-yuzhao@google.com> <20220407031525.2368067-8-yuzhao@google.com> <87zgk7xi13.fsf@linux.ibm.com> In-Reply-To: From: Yu Zhao Date: Wed, 27 Apr 2022 00:00:47 -0600 Message-ID: Subject: Re: [PATCH v10 07/14] mm: multi-gen LRU: exploit locality in rmap To: Aneesh Kumar K V Cc: Stephen Rothwell , Linux-MM , Andi Kleen , Andrew Morton , Barry Song <21cnbao@gmail.com>, Catalin Marinas , Dave Hansen , Hillf Danton , Jens Axboe , Jesse Barnes , Johannes Weiner , Jonathan Corbet , Linus Torvalds , Matthew Wilcox , Mel Gorman , Michael Larabel , Michal Hocko , Mike Rapoport , Rik van Riel , Vlastimil Babka , Will Deacon , Ying Huang , Linux ARM , "open list:DOCUMENTATION" , linux-kernel , Kernel Page Reclaim v2 , "the arch/x86 maintainers" , 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" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Apr 26, 2022 at 11:31 PM Aneesh Kumar K V wrote: > > On 4/27/22 10:08 AM, Yu Zhao wrote: > > On Tue, Apr 26, 2022 at 10:33 PM Aneesh Kumar K.V > > wrote: > >> > >> Yu Zhao writes: > >> > >> .... > >> > >> 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++; > >>> + } > >> > >> Is it required to update referenced here? we do that below after > >> clearing the young bit. Or is the goal to identify whether we found any > >> young pte around? > > > > referenced++ is needed because lru_gen_look_around() also clears the > > young bit in pvmw.pte. And ptep_clear_flush_young_notify() will return > > false unless mmu notifier returns true. > > should we then use a mmu notifier variant of clear_young in > lru_gen_look_around() ? Generally multiple sets of page tables don't share the same memory locality. E.g., for kvm, its secondary page tables map to guest physical address space, whose locality is very different from typical virtual address space. In this case lru_gen_look_around() is generally not helpful. For this reason, we don't use the mmu notifier variants of pte_young() or clear_young(). 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 C9548C433F5 for ; Wed, 27 Apr 2022 06:03:18 +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:Cc:To:Subject:Message-ID:Date:From: In-Reply-To:References:MIME-Version:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=wTUjEdl6Il/RjU/UKL7QewzjEEizsxkEZadUdwlM074=; b=ULFmM1dmhs/Jxn xMtf9577nq/5AycoX7rVzTF1lFxUzKChqyc4oduxNp+X80yCKGzmHzbEO/3wmGB6AvUba7uvl+U42 7UKyRF0CZsEszjC7SY/ueYc7JMlIQNgdf8QmDRTZH5lLb7JcNbRcUWi6h/SlEQ6kN7+nqg+9QIfTE BXzkMGPlSYegUiEkGtoWFPLCMFIlgBAnU25T0QdTpqQYNpliqxytzGaWGxCZ0dr9/8tow7EyKk4Qm Ty3eSSmN1KYdB7MMVxnFW5hvuibWNWKgbsgk7jmvsU2+vHi8hKuGQzISx4JppHw+Iqpaaf4/berkw 7bu5sAsvW1Lm4Wv/Y1Mg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1njajz-00HX1r-6X; Wed, 27 Apr 2022 06:01:31 +0000 Received: from mail-ua1-x932.google.com ([2607:f8b0:4864:20::932]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1njajv-00HWzm-CA for linux-arm-kernel@lists.infradead.org; Wed, 27 Apr 2022 06:01:29 +0000 Received: by mail-ua1-x932.google.com with SMTP id i16so249873uat.5 for ; Tue, 26 Apr 2022 23:01:24 -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=eEenBPTT+A8NftOZwlTNAzvJdJr06gaMpQKvN58cBsM=; b=rB0CdeG5tjzYHEixLfnyBxBN8Py8g9fJZ/W8h2JVMHNdvkQi0/EHFiqOmCaacpuXFU 628XUqXPgbnn7+t5QuJUsrZg0LS0BjRpKvOscPq6mLwMsr41GQdTFZiIRZmRxLrzsb7t uvwjkz4lksY9DHaFI2FD37wIh3fNKYVnM/qZpX2u6qfDLcCGqIpzO7YPwg8nfDpIxdJH dm14+oFOJdwhUJoom7iHvraVdDFnJTXC3IshjVIwoqTpyXHZno4TMfXJ9p98ndxMp3bU 5WMIyH8nXzVUxgIPlTZ4F3VnO56QrYBo2felfbpX4PnzYDfDjf311D8Hgg8LcOQygVEK qH0g== 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=eEenBPTT+A8NftOZwlTNAzvJdJr06gaMpQKvN58cBsM=; b=o5M0OpkfuxpJ+5LKyhne76lrd9jx1LLm3txsIdlbMAxbtHwcIyBa7pjUHexyDlrM/L cRuf0+c1FBcQxsEEVhKs54U3CdXkGq797UoS6/J9D99iTKTMGkh2xJ3JSjOsj1JXE+gu QePWbnBVfuDl/A2MUKEs56RLKrVNTxlZRHcHV9pW0PCmx/U5nv/Y5b/ALgN9CUoTxeH4 g53ayKuaq5m03sIyP0TXxMH8e1yK4URBfjNQrAyG51521NlLrOotX73yvJZJTTuMZ7Xn hRxFnzOI8MWnUI33BLe2cI7zMzCN2aw+ual/jIeElsaxx6nqWmF4HEllfdigWD2u+wsO rD6Q== X-Gm-Message-State: AOAM531inthGHIXb0R4ruv6oy0JlqSERT/XdDVELYbB5y3tDMYZOBiGl 0CJoB2hkmeXuTiSLobUCz+T0c34GbGSRY+4CNKY6Pg== X-Google-Smtp-Source: ABdhPJxgvGijbH7jxYuaIKjHR/e2sUn7feZnfqFOoKQXZ9QvO1ndFMrJOawwmWogeWkH02N9ILsUauEjnILfGArW+Qs= X-Received: by 2002:ab0:77d5:0:b0:352:42d7:88c2 with SMTP id y21-20020ab077d5000000b0035242d788c2mr7891618uar.1.1651039283985; Tue, 26 Apr 2022 23:01:23 -0700 (PDT) MIME-Version: 1.0 References: <20220407031525.2368067-1-yuzhao@google.com> <20220407031525.2368067-8-yuzhao@google.com> <87zgk7xi13.fsf@linux.ibm.com> In-Reply-To: From: Yu Zhao Date: Wed, 27 Apr 2022 00:00:47 -0600 Message-ID: Subject: Re: [PATCH v10 07/14] mm: multi-gen LRU: exploit locality in rmap To: Aneesh Kumar K V Cc: Stephen Rothwell , Linux-MM , Andi Kleen , Andrew Morton , Barry Song <21cnbao@gmail.com>, Catalin Marinas , Dave Hansen , Hillf Danton , Jens Axboe , Jesse Barnes , Johannes Weiner , Jonathan Corbet , Linus Torvalds , Matthew Wilcox , Mel Gorman , Michael Larabel , Michal Hocko , Mike Rapoport , Rik van Riel , Vlastimil Babka , Will Deacon , Ying Huang , Linux ARM , "open list:DOCUMENTATION" , linux-kernel , Kernel Page Reclaim v2 , "the arch/x86 maintainers" , 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 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220426_230127_438575_042B6E4B X-CRM114-Status: GOOD ( 20.23 ) 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, Apr 26, 2022 at 11:31 PM Aneesh Kumar K V wrote: > > On 4/27/22 10:08 AM, Yu Zhao wrote: > > On Tue, Apr 26, 2022 at 10:33 PM Aneesh Kumar K.V > > wrote: > >> > >> Yu Zhao writes: > >> > >> .... > >> > >> 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++; > >>> + } > >> > >> Is it required to update referenced here? we do that below after > >> clearing the young bit. Or is the goal to identify whether we found any > >> young pte around? > > > > referenced++ is needed because lru_gen_look_around() also clears the > > young bit in pvmw.pte. And ptep_clear_flush_young_notify() will return > > false unless mmu notifier returns true. > > should we then use a mmu notifier variant of clear_young in > lru_gen_look_around() ? Generally multiple sets of page tables don't share the same memory locality. E.g., for kvm, its secondary page tables map to guest physical address space, whose locality is very different from typical virtual address space. In this case lru_gen_look_around() is generally not helpful. For this reason, we don't use the mmu notifier variants of pte_young() or clear_young(). _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel