From: "Lorenzo Stoakes (ARM)" <ljs@kernel.org>
To: "David Hildenbrand (Arm)" <david@kernel.org>
Cc: Mikhail Gavrilov <mikhail.v.gavrilov@gmail.com>,
Andrew Morton <akpm@linux-foundation.org>,
Dave Hansen <dave.hansen@linux.intel.com>,
"Liam R . Howlett" <liam@infradead.org>,
Vlastimil Babka <vbabka@kernel.org>,
Mike Rapoport <rppt@kernel.org>,
Suren Baghdasaryan <surenb@google.com>,
Michal Hocko <mhocko@suse.com>,
Vishal Moola <vishal.moola@gmail.com>,
Ingo Molnar <mingo@kernel.org>,
Lu Baolu <baolu.lu@linux.intel.com>,
Jason Gunthorpe <jgg@nvidia.com>,
Steven Rostedt <rostedt@goodmis.org>,
x86@kernel.org, linux-mm@kvack.org, regressions@lists.linux.dev,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] mm: don't defer freeing kernel page tables while booting
Date: Thu, 24 Sep 2026 10:29:29 +0100 [thread overview]
Message-ID: <arTq_8FGRj7a85kw@gremlin> (raw)
In-Reply-To: <arTmLiTLnxhwohH1@gremlin>
On Thu, Sep 24, 2026 at 09:59:36AM +0100, Lorenzo Stoakes (ARM) wrote:
> On Thu, Sep 24, 2026 at 09:57:57AM +0100, Lorenzo Stoakes (ARM) wrote:
> > On Thu, Sep 24, 2026 at 09:31:40AM +0200, David Hildenbrand (Arm) wrote:
> > > On 9/24/26 09:28, Mikhail Gavrilov wrote:
> > > > On 9/24/26 09:07, David Hildenbrand (Arm) wrote:
> > > >> Should we instead simply skip the
> > > >>
> > > >> schedule_work(&kernel_pgtable_work.work);
> > > >>
> > > >> and rely on anybody freeing stuff later to just free that one alongside?
> > > >>
> > > >> That avoids throwing in more freeing handling.
> > > >
> > > > Yes, that is simpler, and the early table then goes through the same
> > > > IOMMU flush as every other one, so there is no need to reason about
> > > > what an IOMMU can see during boot. The only cost is that it waits on
> > > > the list until the next kernel page table is freed after boot.
> > >
> > > If we're worried about that actually causing problems we could drain the list at
> > > a later part during the boot stage. I'd suspect we free something else later
> > > already and simply drain the list ...
>
> And on that, yes, I don't think there's anything to worry about there.
Though maybe it's worth ensuring the drain? Shouldn't be hard, so like:
diff --git a/mm/pgtable-generic.c b/mm/pgtable-generic.c
index f3754cefb19e..67f286169632 100644
--- a/mm/pgtable-generic.c
+++ b/mm/pgtable-generic.c
@@ -457,12 +457,29 @@ static void kernel_pgtable_work_func(struct work_struct *work)
__pagetable_free(pt);
}
+static void schedule_kernel_pgtable_free(void)
+{
+ schedule_work(&kernel_pgtable_work.work);
+}
+
void pagetable_free_kernel(struct ptdesc *pt)
{
spin_lock(&kernel_pgtable_work.lock);
list_add(&pt->pt_list, &kernel_pgtable_work.list);
spin_unlock(&kernel_pgtable_work.lock);
- schedule_work(&kernel_pgtable_work.work);
+ /* No workqueues exist yet. */
+ if (system_state != SYSTEM_BOOTING)
+ schedule_kernel_pgtable_free();
}
+
+static int kernel_pgtable_drain_early(void)
+{
+ /* Drain any early kernel page table frees. */
+ schedule_kernel_pgtable_free();
+ return 0;
+}
+
+core_initcall(kernel_pgtable_drain_early);
+
#endif
--
Cheers, Lorenzo
next prev parent reply other threads:[~2026-09-24 9:29 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-24 6:43 [PATCH] mm: don't defer freeing kernel page tables while booting Mikhail Gavrilov
2026-09-24 7:07 ` David Hildenbrand (Arm)
2026-09-24 7:28 ` Mikhail Gavrilov
2026-09-24 7:31 ` David Hildenbrand (Arm)
2026-09-24 8:57 ` Lorenzo Stoakes (ARM)
2026-09-24 8:59 ` Lorenzo Stoakes (ARM)
2026-09-24 9:29 ` Lorenzo Stoakes (ARM) [this message]
2026-09-24 7:38 ` Lorenzo Stoakes (ARM)
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=arTq_8FGRj7a85kw@gremlin \
--to=ljs@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=baolu.lu@linux.intel.com \
--cc=dave.hansen@linux.intel.com \
--cc=david@kernel.org \
--cc=jgg@nvidia.com \
--cc=liam@infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mhocko@suse.com \
--cc=mikhail.v.gavrilov@gmail.com \
--cc=mingo@kernel.org \
--cc=regressions@lists.linux.dev \
--cc=rostedt@goodmis.org \
--cc=rppt@kernel.org \
--cc=surenb@google.com \
--cc=vbabka@kernel.org \
--cc=vishal.moola@gmail.com \
--cc=x86@kernel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.