On Tue, Sep 01, 2026 at 11:54:47AM -0400, Liam R. Howlett wrote: > On 26/09/01 04:28PM, Kiryl Shutsemau wrote: > > On Tue, Sep 01, 2026 at 03:41:17PM +0100, Lorenzo Stoakes (ARM) wrote: > > > On Tue, Sep 01, 2026 at 11:24:08AM -0300, Jason Gunthorpe wrote: > > > > On Tue, Sep 01, 2026 at 03:12:45PM +0100, Lorenzo Stoakes (ARM) wrote: > > > > > > > > > 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
