From: Mikhail Gavrilov <mikhail.v.gavrilov@gmail.com>
To: David Hildenbrand <david@kernel.org>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Dave Hansen <dave.hansen@linux.intel.com>,
Lorenzo Stoakes <ljs@kernel.org>,
"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 12:28:19 +0500 [thread overview]
Message-ID: <20260924072819.33277-1-mikhail.v.gavrilov@gmail.com> (raw)
In-Reply-To: <41a59ba9-039e-454f-8d31-f647db802ada@kernel.org>
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.
I'll send a v2 that way once I have booted it here.
next prev parent reply other threads:[~2026-09-24 7:28 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 [this message]
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)
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=20260924072819.33277-1-mikhail.v.gavrilov@gmail.com \
--to=mikhail.v.gavrilov@gmail.com \
--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=ljs@kernel.org \
--cc=mhocko@suse.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox