Thread (31 messages) flat view 31 messages, 4 authors, 4d ago

Re: [PATCH 01/12] mm/huge_memory: zap deposited page tables after an RCU grace period

From: Jason Gunthorpe <jgg@ziepe.ca>
Date: 2026-09-01 16:06:18
Also in: linux-alpha, linux-arch, linux-m68k, linux-mips, linux-mm, linux-riscv, linux-s390, linux-sh, linux-um, lkml, loongarch, sparclinux

On Tue, Sep 01, 2026 at 11:54:47AM -0400, Liam R. Howlett wrote:
On 26/09/01 04:28PM, Kiryl Shutsemau wrote:
quoted
On Tue, Sep 01, 2026 at 03:41:17PM +0100, Lorenzo Stoakes (ARM) wrote:
quoted
On Tue, Sep 01, 2026 at 11:24:08AM -0300, Jason Gunthorpe wrote:
quoted
On Tue, Sep 01, 2026 at 03:12:45PM +0100, Lorenzo Stoakes (ARM) wrote:
quoted
It won't be costly at the time of the calls obviously as its deferred. Maybe
increase some time spent in softirq but again is 512x that big of a deal?

I'm not sure how you'd both defer the free and somehow utilise mmu_gather here
either really, certainly not without it becoming extremely messy.
The less costly version is to thread the page to be freed onto the
mmu_gather through a linked list in the struct page memory. This is
super cheap since it is just a singly linked list operation.

Then when the mmu_gather is flushed it does a single call_rcu using
the rcu head of the struct page of the head of the list. The callback
clears the entire linked list of pages.
If you are going through the trouble of doing this on your side with a
custom rcu callback, it might be better to pack the pointers in a way
that does not need to pointer chase through a linked list.
Well, I have 8 bytes of memory in a struct page and can't allocate in
these paths, so IDK there is another option..

Jason
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help