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 0916ECD8CAE for ; Tue, 10 Oct 2023 18:08:22 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 5DF4D8E0003; Tue, 10 Oct 2023 14:08:21 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 58E788D0002; Tue, 10 Oct 2023 14:08:21 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 47CF08E0003; Tue, 10 Oct 2023 14:08:21 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id 37E578D0002 for ; Tue, 10 Oct 2023 14:08:21 -0400 (EDT) Received: from smtpin18.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id A56D01202BE for ; Tue, 10 Oct 2023 18:08:20 +0000 (UTC) X-FDA: 81330336360.18.347D666 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf04.hostedemail.com (Postfix) with ESMTP id 5E5B44001D for ; Tue, 10 Oct 2023 18:08:18 +0000 (UTC) Authentication-Results: imf04.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=CpFr2Wzb; dmarc=none; spf=none (imf04.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1696961298; a=rsa-sha256; cv=none; b=mmvgHb5m+4jG/3jnlbcmAlWre7BciqXytebXQrhA5hPyxYavuRoJY88Rb6PJW1AIUoow8z JPUG5IacQXSS091W9Az8J6IqMpqencVJcko9ffvo47xvlJCa6abqQIiNSzXbvxgJiU/y55 BbZlaDPEyiq8qS/GsnZOYFwo2D8zuyo= ARC-Authentication-Results: i=1; imf04.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=CpFr2Wzb; dmarc=none; spf=none (imf04.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1696961298; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=Ue9Ky4dslnBeYc2Bd+KE4/eZdEViH3G2390HRVXyM2k=; b=kAtDyJb1WptYu+d1bGp7VSjPd4yO6vIyn4Frtr2XU6iMHFYwwxHoxs0Unuo5hq3MYtz0px KPrnSYI57TGr5xDii/YXANvDflYO/nAcYbIm389mtJQOVFINjGMNMpaGlRwlFCr1Vv23Mw EqAMZ0WFjIeeNxyyRAVS0pvCyDuK6QA= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=Ue9Ky4dslnBeYc2Bd+KE4/eZdEViH3G2390HRVXyM2k=; b=CpFr2Wzbk31eJjZxLkYJYJ3n6O I5daE4oBzdJr1DHtCQPeRb2cdePtT8wSbUJxgAxkkWvEuN+C0Ns1dTUjkt20uOngsXcOzWA7VbrFh dh5zW0xkIkzQLtfInEtVvQ7wrwEpXe2M3j1/gpJc04Y1Bl5infjNbFLzbPxZS5WT0r6IfZQ187ZzB MKIo7YqPT/QIyrl+5rYF477gTM3cgfzuVS8xhqksDB8g0ueLilFhmW18go0BKkclARDbGEd5kbR6H 7SAoBzpySB86je1B8sJ981V/qWtDbydGLQ7d5501XjdyMMTwGbWJ+lciF3aeW+JV8SDgqY7wrNplz l1wQXrGg==; Received: from willy by casper.infradead.org with local (Exim 4.94.2 #2 (Red Hat Linux)) id 1qqH9T-0062Dc-Aa; Tue, 10 Oct 2023 18:08:15 +0000 Date: Tue, 10 Oct 2023 19:08:15 +0100 From: Matthew Wilcox To: Gregory Price Cc: linux-mm@kvack.org, linux-fsdevel@vger.kernel.org Subject: Re: [PATCH v14 08/39] mm/swap: Add folio_mark_accessed() Message-ID: References: <20210715200030.899216-9-willy@infradead.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspam-User: X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: 5E5B44001D X-Stat-Signature: 7kboe7irokejmd5y5yefeiajbhi9xeg7 X-HE-Tag: 1696961298-595237 X-HE-Meta: U2FsdGVkX18gv3+beKT227AvIYrgXM+fZTV8FF7NDZs7qRRX1nCsS/xzkpIo7tN9ha8NwXs4vma/Q4TXadbYZAZPNhYBrpWzRJYXLHBaU8jdThw4x6nJ0ZwTLxXGSSG+KSs1FzPl/fwlTrH9TOAcuNFKz6S2ugHfDWRkWBQ2VMyKjtY4pWS8rXfqvMAIff7TfrLi7FJWrPbmjHTjE6zxNh70yvtt2i2LU87K5tW2YvWzy3QO9viZb+MSBNLyonFi39aqVZY49fhaxb3xPma59FAa6RKDlRnwi3zDl+Kfr56RTlGXM6e2MBo+h3HtBXeOtkeqAG2X4kD0l9zIBJABI2iazUlhKjt9xtfkYZ30pOpMJeGKf9exBtBXnhmCRPHNOWv8Am2CDsqyiX4+8yFiL1FuAzC3oJHX2p8ftymWWPtf51yADw2tshnNiZIEKdQ9uJkjCck1nYhqnhlF4GmO5spKTfjMNM/c+XqE6hQ/CDicwdCvKsktGrmXIl7DWFa1VHit2cFgjU60i5jyQVnMvRazwEQwUVha4cR0odJnlLnNQM1dkEZ1GJSZJf8yFNE9OwfLL/73fJFl0mB/ZjZkO5H1uIKZiEx6RYz+o+FASp74B5uArngZKlORi83nxxdQUlnPz8H75cMA7/+An78uZc1s87Qy+/gymERE1v/AwhEErPfBJ4D4lafn2AuozAI+vYM+dVUrN3f7BS5mChyRgeJ549TY9fudPrP5Dm5mmy7Jm3/bHyM84ITpReR0X38+SiRH3KGDvu7TFMSUEqUoJ6O0qjx16HfgbPO9hectG9eJ02pZgSpmBb8oHwZ89/8qhBlq4IiJhziQ8+q7E1+r0ZXKYhyvBTHQfwLGfBU0NDgFnD0Nie5KEsk4BCgGZW0NyLu/0+xaudJwaWtfgQtDjI2A50OgDui4AKUPDRKYAGkRGtSVYJmgqNSF9xTK1n6Lu65+U2swp1JQtPv3Jcx O8/bH7pe jxeZjxKWdDiCa8S6LJgefI6TK4A2V5zlAjMuZa4YLOLL+Qo17K689HpK0ARGhnuahGDm+0aOs+fx8KLTKoFIWRSMXOwjBNrqbG2tRI3euUTQCnDMxRSWd6O+1lqxdLtox8xEg8c8UWYD2ZghCJ1TF6kkuWYwW82g3LcGhpqxSwSurskBuE86nOq098w== 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, Oct 08, 2023 at 11:34:45AM -0400, Gregory Price wrote: > On Thu, 15 Jul 2021 20:59:59 +0100, Matthew Wilcox wrote > > +void mark_page_accessed(struct page *page) > > +{ > > + folio_mark_accessed(page_folio(page)); > > +} > > +EXPORT_SYMBOL(mark_page_accessed); > ... snip ... > > > > @@ -430,36 +430,34 @@ static void __lru_cache_activate_page(struct page *page) > > * When a newly allocated page is not yet visible, so safe for non-atomic ops, > > * __SetPageReferenced(page) may be substituted for mark_page_accessed(page). > > */ > > -void mark_page_accessed(struct page *page) > > +void folio_mark_accessed(struct folio *folio) > > { > > - page = compound_head(page); > > - > > - if (!PageReferenced(page)) { > > - SetPageReferenced(page); > > - } else if (PageUnevictable(page)) { > > + if (!folio_test_referenced(folio)) { > > + folio_set_referenced(folio); > > + } else if (folio_test_unevictable(folio)) { > > Hi Matthew, > > My colleagues and I have been testing some page-tracking algorithms and > we tried using the reference bit by using /proc/pid/clear_clears, > /proc/pid/pagemap, and /proc/kpageflags. > > I'm not 100% of the issue, but we're finding some inconsistencies when > tracking page reference bits, and this seems to be at least one of the > patches we saw that might be in the mix. > > >From reading up on folios, it seems like this change prevents each > individual page in a folio from being marked referenced, and instead > prefers to simply mark the entire folio containing the page as accessed. > > When looking at the proc/ interface, it seems like it is still > referencing the page and not using the folio for a page (see below). > > Our current suspicion is that since only the folio head gets marked > referenced, any pages inside the folio that aren't the head will > basically never be marked referenced, leading to an inconsistent view. > > I'm curious your thoughts on whether (or neither): > > a) Should we update kpageflags_read to use page_folio() and get the > folio flags for the head page > > or > > b) the above change to mark_page_accessed() should mark both the > individual page flags to accessed as well as the folio head accessed. Hi Greg, thanks for reaching out. The referenced bit has been tracked on what is now known as a per-folio basis since commit 8cb38fabb6bc in 2016. That is, if you tried to SetPageReferenced / ClearPageReferenced / test PageReferenced on a tail page, it would redirect to the head page in order to set/clear/test the bit in the head page's flags field. That's not to say that all the code which sets/checks/tests this really understands that! We've definitely found bugs during the folio work where code has mistakenly assumed that operations on a tail page actually affect that page rather than the whole allocation. There's also code which is now being exposed to compound pages for the first time, and is not holding up well. I hope that's helpful in finding the bug you're chasing. > Thanks for your time. > Gregory Price > > > (relevant fs/proc/page.c code:) > > > static ssize_t kpageflags_read(struct file *file, char __user *buf, > size_t count, loff_t *ppos) > { > ... snip ... > ppage = pfn_to_online_page(pfn); > > if (put_user(stable_page_flags(ppage), out)) { > ret = -EFAULT; > break; > } > ... snip ... > } > > > u64 stable_page_flags(struct page *page) > { > ... snip ... > k = page->flags; > ... snip ... > }