From: Rik van Riel <riel@surriel.com>
To: Vinay Banakar <vny@google.com>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org
Cc: akpm@linux-foundation.org, willy@infradead.org, mgorman@suse.de,
Wei Xu <weixugc@google.com>, Greg Thelen <gthelen@google.com>
Subject: Re: [PATCH] mm: Optimize TLB flushes during page reclaim
Date: Wed, 22 Jan 2025 23:17:20 -0500 [thread overview]
Message-ID: <135b6d6fad6083bfd11a9dc98fad69756b51c59d.camel@surriel.com> (raw)
In-Reply-To: <CALf+9Yc3WjbG89uRWiDC_qYshJ5z_9WCrbEJe42Vbv+gJjs26g@mail.gmail.com>
On Mon, 2025-01-20 at 16:47 -0600, Vinay Banakar wrote:
>
> This patch instead optimizes the process by batching operations,
> issuing one IPI per PMD instead of per page. This reduces interrupts
> by a factor of 512 and enables batching page submissions to BIO. The
> new approach:
> 1. Collect dirty pages that need to be written back
> 2. Issue a single TLB flush for all dirty pages in the batch
> 3. Process the collected pages for writebacks (submit to BIO)
>
I see how moving the arch_tlbbatch_flush to
between unmapping the pages, and issuing the
IO could reduce TLB flushing operations
significantly.
However, how does that lead to PMD level
operations?
I don't see any code in your patch that gathers
things at the PMD level. The code simply operates
on whatever folio size is on the list that is
being passed to shrink_folio_list()
Is the PMD level thing some MGLRU specific feature?
>
> I'd appreciate your feedback on this approach, especially on the
> correctness of batched BIO submissions. Looking forward to your
> comments.
>
Maybe the filesystem people have more comments on
this aspect, but from a VM perspective I suspect
that doing that batch flush in one spot, and then
iterating over the pages should be fine.
My main quibble is with the changelog, and the
comment that refers to "PMD level" operations,
when the code does not appear to be doing any
PMD level coalescing.
--
All Rights Reversed.
next prev parent reply other threads:[~2025-01-23 4:20 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-01-20 22:47 Vinay Banakar
2025-01-21 0:05 ` Vinay Banakar
2025-01-22 8:59 ` Bharata B Rao
2025-01-22 11:09 ` Vinay Banakar
2025-01-22 11:31 ` Bharata B Rao
2025-01-22 13:28 ` Vinay Banakar
2025-01-22 20:05 ` SeongJae Park
2025-01-23 17:11 ` Vinay Banakar
2025-01-23 17:23 ` SeongJae Park
2025-01-23 18:17 ` Matthew Wilcox
2025-01-21 1:43 ` Byungchul Park
2025-01-21 18:03 ` Vinay Banakar
2025-01-23 4:17 ` Rik van Riel [this message]
2025-01-23 19:16 ` Vinay Banakar
2025-01-28 22:01 ` Rik van Riel
2025-03-17 19:20 ` Rik van Riel
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=135b6d6fad6083bfd11a9dc98fad69756b51c59d.camel@surriel.com \
--to=riel@surriel.com \
--cc=akpm@linux-foundation.org \
--cc=gthelen@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mgorman@suse.de \
--cc=vny@google.com \
--cc=weixugc@google.com \
--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