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 68727C433F5 for ; Fri, 11 Mar 2022 22:58:11 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id F22018D0002; Fri, 11 Mar 2022 17:58:10 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id EA8F38D0001; Fri, 11 Mar 2022 17:58:10 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D4A9C8D0002; Fri, 11 Mar 2022 17:58:10 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0070.hostedemail.com [216.40.44.70]) by kanga.kvack.org (Postfix) with ESMTP id C60EC8D0001 for ; Fri, 11 Mar 2022 17:58:10 -0500 (EST) Received: from smtpin26.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id 7087C9F31E for ; Fri, 11 Mar 2022 22:58:10 +0000 (UTC) X-FDA: 79233620340.26.97D69AC Received: from mail-vk1-f169.google.com (mail-vk1-f169.google.com [209.85.221.169]) by imf15.hostedemail.com (Postfix) with ESMTP id E3BE5A0014 for ; Fri, 11 Mar 2022 22:58:09 +0000 (UTC) Received: by mail-vk1-f169.google.com with SMTP id c4so5458274vkq.9 for ; Fri, 11 Mar 2022 14:58:09 -0800 (PST) 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:content-transfer-encoding; bh=3INdYjmD9sI3AAGt1tE2s/Am9WLmWC+N03DHnuY4rE8=; b=BMA7qz0hmDXjgLAj/07b1iUaF7Hpsjn69duyTb+GziOeEl6FfVlZDbJDnlOKFb5OxL 993gwyQ2uOEj3GwTJER0T9zTHJQ6k2YiGQTupxTGAeMkt/rxQ8SU7B9al7D4z9jq+inU xbnrI77JFap8h53TWHjivFVxM/5MoRxNBSh2yX54H67Yp6YZMsQAViCyWkISwhr/YT+i mF5wyHwgkInp+C4d5kf++Um69oOINKpvHpy1b28ckD6Y+qNFCGvwWa9cJ9efFbon6Epm qL/hHNgx/Su35VLn9pfl0NE6jHYctKc0W1IDlZ6EMyJaDiqCHBSVDl5l8Gtv573d3IuH NkEA== 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:content-transfer-encoding; bh=3INdYjmD9sI3AAGt1tE2s/Am9WLmWC+N03DHnuY4rE8=; b=19yDDYq9vt9dyE9CgeP+20GPfJNvYTGbKH+MuIF0zRhi32uw38kTZxjUXpd6Hh4m/O ag3OAjAPRgVmGoU5J9k4pOgLah33P3XbqQByk/QUXfBvAMmTNsSdSLbkRHVVvL3ZBj7R d3lph2aRFA88GpOopUvEo7vss9u1s/x0Sjh2uFRtq2M9jNKPtFsCAHS9UAg2EtwWxDGX 7kjDJziuqHaeSjX5IADRQGqfOkdPJWez8v1hCe5SkfhL9pB7BdOIHPxh8O0wSnBHyqxP Ys0OvXCvdWqfXjQMW5Zdg9A62OCH1tqp4UEJTbQirPBmdYGtFQvASZkUxXynDEYbmUBA eI0A== X-Gm-Message-State: AOAM532t+a2r6OO2x5MfQBrESEqCfXScCCq00SAwOS+DUl8OgiHHYXBW 1MvxPckb29H0bAOrJ++KEsLY7uMJ/zF7adrtxIOCKA== X-Google-Smtp-Source: ABdhPJwGpXBfC5BGWFXcbt51OotnQdLdCIZrxqrjphxJw0BNDdEab0gCbm4RnWAIGbVNilKBQ/CyJES1Xl9HPBWgrnk= X-Received: by 2002:a05:6122:2089:b0:337:bb38:9145 with SMTP id i9-20020a056122208900b00337bb389145mr5955292vkd.14.1647039488964; Fri, 11 Mar 2022 14:58:08 -0800 (PST) MIME-Version: 1.0 References: <20220309021230.721028-1-yuzhao@google.com> <20220309021230.721028-2-yuzhao@google.com> In-Reply-To: From: Yu Zhao Date: Fri, 11 Mar 2022 15:57:57 -0700 Message-ID: Subject: Re: [PATCH v9 01/14] mm: x86, arm64: add arch_has_hw_pte_young() To: Barry Song <21cnbao@gmail.com> Cc: Andrew Morton , Linus Torvalds , Andi Kleen , Aneesh Kumar , Catalin Marinas , Dave Hansen , Hillf Danton , Jens Axboe , Jesse Barnes , Johannes Weiner , Jonathan Corbet , Matthew Wilcox , Mel Gorman , Michael Larabel , Michal Hocko , Mike Rapoport , Rik van Riel , Vlastimil Babka , Will Deacon , Ying Huang , LAK , Linux Doc Mailing List , LKML , Linux-MM , Kernel Page Reclaim v2 , x86 , 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" Content-Transfer-Encoding: quoted-printable X-Stat-Signature: dnsy8ehx4dpih1ocbzhb3h3tto1sa6ez Authentication-Results: imf15.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=BMA7qz0h; spf=pass (imf15.hostedemail.com: domain of yuzhao@google.com designates 209.85.221.169 as permitted sender) smtp.mailfrom=yuzhao@google.com; dmarc=pass (policy=reject) header.from=google.com X-Rspam-User: X-Rspamd-Server: rspam12 X-Rspamd-Queue-Id: E3BE5A0014 X-HE-Tag: 1647039489-774036 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 Fri, Mar 11, 2022 at 3:55 AM Barry Song <21cnbao@gmail.com> wrote: > > On Wed, Mar 9, 2022 at 3:47 PM Yu Zhao wrote: > > > > Some architectures automatically set the accessed bit in PTEs, e.g., > > x86 and arm64 v8.2. On architectures that do not have this capability, > > clearing the accessed bit in a PTE usually triggers a page fault > > following the TLB miss of this PTE (to emulate the accessed bit). > > > > Being aware of this capability can help make better decisions, e.g., > > whether to spread the work out over a period of time to reduce bursty > > page faults when trying to clear the accessed bit in many PTEs. > > > > Note that theoretically this capability can be unreliable, e.g., > > hotplugged CPUs might be different from builtin ones. Therefore it > > should not be used in architecture-independent code that involves > > correctness, e.g., to determine whether TLB flushes are required (in > > combination with the accessed bit). > > > > Signed-off-by: Yu Zhao > > Acked-by: Brian Geffon > > Acked-by: Jan Alexander Steffens (heftig) > > Acked-by: Oleksandr Natalenko > > Acked-by: Steven Barrett > > Acked-by: Suleiman Souhlal > > Acked-by: Will Deacon > > Tested-by: Daniel Byrne > > Tested-by: Donald Carr > > Tested-by: Holger Hoffst=C3=A4tte > > Tested-by: Konstantin Kharlamov > > Tested-by: Shuang Zhai > > Tested-by: Sofia Trinh > > Tested-by: Vaibhav Jain > > --- > > Reviewed-by: Barry Song Thanks. > i guess arch_has_hw_pte_young() isn't called that often in either > mm/memory.c or mm/vmscan.c. > Otherwise, moving to a static key might help. Is it? MRS shouldn't be slower than either branch of a static key. With a static key, we only can optimize one of the two cases. There is a *theoretical* problem with MRS: ARM specs don't prohibit a physical CPU to support both cases (on different logical CPUs).