From: Alexander Gordeev <agordeev@linux.ibm.com>
To: "Matthew Wilcox (Oracle)" <willy@infradead.org>
Cc: Gerald Schaefer <gerald.schaefer@linux.ibm.com>,
Heiko Carstens <hca@linux.ibm.com>,
Vasily Gorbik <gor@linux.ibm.com>,
Claudio Imbrenda <imbrenda@linux.ibm.com>,
Christian Borntraeger <borntraeger@linux.ibm.com>,
linux-mm@kvack.org
Subject: Re: [PATCH] s390: Remove PageDirty check inside mk_pte()
Date: Mon, 20 Jan 2025 17:39:43 +0100 [thread overview]
Message-ID: <Z458T8NbllQ+IePC@li-008a6a4c-3549-11b2-a85c-c5cc2836eea2.ibm.com> (raw)
In-Reply-To: <20250116212338.653160-1-willy@infradead.org>
On Thu, Jan 16, 2025 at 09:23:36PM +0000, Matthew Wilcox (Oracle) wrote:
Hi Matthew,
> In commit abf09bed3cce ("s390/mm: implement software dirty bits"),
> the rationale for adding the PageDirty() test was:
>
> To avoid an excessive number of additional faults the
> mk_pte primitive checks for PageDirty if the pgprot value
> allows for writes and pre-dirties the pte. That avoids all
> additional faults for tmpfs and shmem pages until these
> pages are added to the swap cache.
>
> shmem does not mark newly allocated folios as dirty since 2016 (commit
> 75edd345e8ed) so this test has been ineffective since then. It still
> triggers for some calls to mk_pte(), but those calls are usually
> followed with other calls to pte_mkdirty() making the ones inside
> s390's mk_pte() redundant.
>
> Signed-off-by: Matthew Wilcox (Oracle) <willy@infradead.org>
> ---
> arch/s390/include/asm/pgtable.h | 5 +----
> 1 file changed, 1 insertion(+), 4 deletions(-)
>
> Please check this doesn't cause any real world performance issues.
> Alexander and I briefly discussed this last year:
> https://lore.kernel.org/linux-mm/20240814154427.162475-5-willy@infradead.org/
> but then I missed his followup on August 22nd, and thought it best to
> reopen the conversation with a fresh patch to test.
I tried to take exactly this approach last year, but dropped the ball.
Despite the commit 75edd345e8ed claim above I still observed that a read
access to shmem page could end up in creation of a dirty PTE:
handle_pte_fault() -> do_pte_missing() -> do_fault() ->
do_read_fault() -> finish_fault() -> set_pte_range() -> mk_pte()
Our internal discussion (among other things) ended up in a need to really
understand where the faults are coming from.
Further, a cursory LTP test was showing ~18K page faults increase, which
I did not confirm. That is the first thing I will re-do.
Whether this change is a pre-requisite for something or what is your aim
wrt to this patch?
> diff --git a/arch/s390/include/asm/pgtable.h b/arch/s390/include/asm/pgtable.h
> index 48268095b0a3..4c7e2fc2b5ff 100644
> --- a/arch/s390/include/asm/pgtable.h
> +++ b/arch/s390/include/asm/pgtable.h
> @@ -1443,11 +1443,8 @@ static inline pte_t mk_pte_phys(unsigned long physpage, pgprot_t pgprot)
> static inline pte_t mk_pte(struct page *page, pgprot_t pgprot)
> {
> unsigned long physpage = page_to_phys(page);
> - pte_t __pte = mk_pte_phys(physpage, pgprot);
>
> - if (pte_write(__pte) && PageDirty(page))
> - __pte = pte_mkdirty(__pte);
> - return __pte;
> + return mk_pte_phys(physpage, pgprot);
> }
>
> #define pgd_index(address) (((address) >> PGDIR_SHIFT) & (PTRS_PER_PGD-1))
Thanks!
next prev parent reply other threads:[~2025-01-20 16:40 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-01-16 21:23 Matthew Wilcox (Oracle)
2025-01-20 16:39 ` Alexander Gordeev [this message]
2025-01-20 19:01 ` David Hildenbrand
2025-01-30 22:12 ` Matthew Wilcox
2025-02-03 13:03 ` Alexander Gordeev
2025-02-12 12:44 ` Alexander Gordeev
2025-02-12 13:08 ` Claudio Imbrenda
2025-02-12 16:43 ` Matthew Wilcox
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Z458T8NbllQ+IePC@li-008a6a4c-3549-11b2-a85c-c5cc2836eea2.ibm.com \
--to=agordeev@linux.ibm.com \
--cc=borntraeger@linux.ibm.com \
--cc=gerald.schaefer@linux.ibm.com \
--cc=gor@linux.ibm.com \
--cc=hca@linux.ibm.com \
--cc=imbrenda@linux.ibm.com \
--cc=linux-mm@kvack.org \
--cc=willy@infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox