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 X-Spam-Level: X-Spam-Status: No, score=-13.3 required=3.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_IN_DEF_DKIM_WL autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 4FC61C433E0 for ; Mon, 15 Mar 2021 01:04:54 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id D44A76186A for ; Mon, 15 Mar 2021 01:04:53 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org D44A76186A Authentication-Results: mail.kernel.org; dmarc=fail (p=reject dis=none) header.from=google.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 3AC556B0006; Sun, 14 Mar 2021 21:04:53 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 35CD56B006C; Sun, 14 Mar 2021 21:04:53 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 1DA6B6B0070; Sun, 14 Mar 2021 21:04:53 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0225.hostedemail.com [216.40.44.225]) by kanga.kvack.org (Postfix) with ESMTP id 00F046B0006 for ; Sun, 14 Mar 2021 21:04:52 -0400 (EDT) Received: from smtpin16.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id BA52D585C for ; Mon, 15 Mar 2021 01:04:52 +0000 (UTC) X-FDA: 77920314024.16.5962574 Received: from mail-il1-f174.google.com (mail-il1-f174.google.com [209.85.166.174]) by imf02.hostedemail.com (Postfix) with ESMTP id 47C84407F8FE for ; Mon, 15 Mar 2021 01:04:52 +0000 (UTC) Received: by mail-il1-f174.google.com with SMTP id g9so7891159ilc.3 for ; Sun, 14 Mar 2021 18:04:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=aAXz8eb+v2Zd51ASzlIswe8D5zMlueWA5CeLpEroo+4=; b=STey9XLF2Yb47zgO895takcZ0V7enD0LHmc59PdqvqqjjddLEaWdK84pqPEPNZa0Xy GXpsNX9mOtWCbQYXmqQMKYtsKXhB83HCuuLnCqyjBGtMSc/dtn9zeySQIH42P7fVZp5W kzxGlg8hpFAErlGCT2H1j2iu12GHxjlIi7xys5GuL7mTmw+lFWvw6igXXUJVEtsNCSnW JRS+VfX2qMaE4DAV2OI2i3+GjLFKw82R5Pi+WX8AQKzyL2yedx3iggG+VL+SX+/LY4Tl W+GUYpyV4LuBDKq9pZIgUO1d7sA0lMYrqWNM4nA0HYbvLGAXpqF8wTYSnWrC3m3YJqJZ zPxg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=aAXz8eb+v2Zd51ASzlIswe8D5zMlueWA5CeLpEroo+4=; b=V3DjDEdJsTGnlmFUQxW83v3rc6DI0hl2R0jkQE5Ri561WiCGMHDAxp2/fakT0DD872 gcAyGUxBItVgMLQpBVU7kkt6QU8ATjC3wS2WG6OV2NTV/O0mGGf34caVlei470TWRLxf LGAferPUP7se5rxWeBaNu4NO+X/TGqmEktcL0e/cF5NQji/z8NrPWbfoTieAoZlKR9L1 yWkDrwla87wLNvDbEHFaGXH8wO5CxndIexoh3p+bvijPdbaIhhh/WSGEiaMJOwDvZsn0 CBT5pMf9TdBvXgXDuNVndK2jDDNAB18OGimPjK7wOjAa241L9x3Wkbv1zip1D1E1cAaL 0s6w== X-Gm-Message-State: AOAM531GUBFNg20RrpFTreh5IxOQUkbKyr4BOxeDla72r7Q9byKaUKT4 F2Wh6CLQWBdJFpYwVwdfEqTnSQ== X-Google-Smtp-Source: ABdhPJxaWwNE2jcuLtNghjyUlNQD+ZViU4UuvsTyIpOuocSqtE4Gk4ltQ6fXH+yJS1UX3tSHJzD8oQ== X-Received: by 2002:a05:6e02:802:: with SMTP id u2mr9407801ilm.298.1615770291601; Sun, 14 Mar 2021 18:04:51 -0700 (PDT) Received: from google.com ([2620:15c:183:200:4d84:eb70:5c32:32b8]) by smtp.gmail.com with ESMTPSA id l14sm6981976ilc.33.2021.03.14.18.04.50 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 14 Mar 2021 18:04:50 -0700 (PDT) Date: Sun, 14 Mar 2021 19:04:45 -0600 From: Yu Zhao To: Zi Yan Cc: Matthew Wilcox , linux-mm@kvack.org, Alex Shi , Andrew Morton , Dave Hansen , Hillf Danton , Johannes Weiner , Joonsoo Kim , Mel Gorman , Michal Hocko , Roman Gushchin , Vlastimil Babka , Wei Yang , Yang Shi , Ying Huang , linux-kernel@vger.kernel.org, page-reclaim@google.com Subject: Re: [PATCH v1 06/14] mm, x86: support the access bit on non-leaf PMD entries Message-ID: References: <20210313075747.3781593-1-yuzhao@google.com> <20210313075747.3781593-7-yuzhao@google.com> <74C83FFE-DC78-40CD-B6BE-00614DC8F125@nvidia.com> <20210314225103.GQ2577561@casper.infradead.org> <3465DA3A-B735-4657-A1E0-89CF5DE0D4FF@nvidia.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3465DA3A-B735-4657-A1E0-89CF5DE0D4FF@nvidia.com> X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: 47C84407F8FE X-Stat-Signature: qatzq7ygpn63nheja7fnngnb6784ztp7 Received-SPF: none (google.com>: No applicable sender policy available) receiver=imf02; identity=mailfrom; envelope-from=""; helo=mail-il1-f174.google.com; client-ip=209.85.166.174 X-HE-DKIM-Result: pass/pass X-HE-Tag: 1615770292-932405 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 Sun, Mar 14, 2021 at 08:27:29PM -0400, Zi Yan wrote: > On 14 Mar 2021, at 20:03, Yu Zhao wrote: > > > On Sun, Mar 14, 2021 at 10:51:03PM +0000, Matthew Wilcox wrote: > >> On Sun, Mar 14, 2021 at 06:12:42PM -0400, Zi Yan wrote: > >>> On 13 Mar 2021, at 2:57, Yu Zhao wrote: > >>> > >>>> Some architectures support the accessed bit on non-leaf PMD entries > >>>> (parents) in addition to leaf PTE entries (children) where pages are > >>>> mapped, e.g., x86_64 sets the accessed bit on a parent when using it > >>>> as part of linear-address translation [1]. Page table walkers who are > >>>> interested in the accessed bit on children can take advantage of this: > >>>> they do not need to search the children when the accessed bit is not > >>>> set on a parent, given that they have previously cleared the accessed > >>>> bit on this parent in addition to its children. > >>>> > >>>> [1]: Intel 64 and IA-32 Architectures Software Developer's Manual > >>>> Volume 3 (October 2019), section 4.8 > >>> > >>> Just curious. Does this also apply to non-leaf PUD entries? Do you > >>> mind sharing which sentence from the manual gives the information? > >> > >> The first few sentences from 4.8: > >> > >> : For any paging-structure entry that is used during linear-address > >> : translation, bit 5 is the accessed flag. For paging-structure > >> : entries that map a page (as opposed to referencing another paging > >> : structure), bit 6 is the dirty flag. These flags are provided for > >> : use by memory-management software to manage the transfer of pages and > >> : paging structures into and out of physical memory. > >> > >> : Whenever the processor uses a paging-structure entry as part of > >> : linear-address translation, it sets the accessed flag in that entry > >> : (if it is not already set). > > Matthew, thanks for the pointer. > > > > > As far as I know x86 is the one that supports this. > > > >> The way they differentiate between the A and D bits makes it clear to > >> me that the A bit is set at each level of the tree, but the D bit is > >> only set on leaf entries. > > > > And the difference makes perfect sense (to me). Kudos to Intel. > > Hi Yu, > > You only introduced HAVE_ARCH_PARENT_PMD_YOUNG but no HAVE_ARCH_PARENT_PUD_YOUNG. > Is it PUD granularity too large to be useful for multigenerational LRU algorithm? Oh, sorry. I overlooked this part of the question. Yes, you are right. We found no measurable performance difference between using and not using the accessed bit on non-leaf PUD entries. For the PMD case, the difference is tiny but still measurable on small systems, e.g., laptops with 4GB memory. It's clear (a few percent in kswapd) on servers with tens of GBs of 4KB pages.