[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20250915144335.GL1024672@nvidia.com>
Date: Mon, 15 Sep 2025 11:43:35 -0300
From: Jason Gunthorpe <jgg@...dia.com>
To: Mike Rapoport <rppt@...nel.org>
Cc: Pratyush Yadav <me@...avpratyush.com>,
Pratyush Yadav <pratyush@...nel.org>,
Andrew Morton <akpm@...ux-foundation.org>,
Alexander Graf <graf@...zon.com>, Baoquan He <bhe@...hat.com>,
Changyuan Lyu <changyuanl@...gle.com>, Chris Li <chrisl@...nel.org>,
Pasha Tatashin <pasha.tatashin@...een.com>,
kexec@...ts.infradead.org, linux-mm@...ck.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH v3 1/2] kho: add support for preserving vmalloc
allocations
On Mon, Sep 15, 2025 at 05:12:27PM +0300, Mike Rapoport wrote:
> > I don't suppose I'd insist on it, but something to consider since you
> > are likely going to do another revision anyway.
>
> I think vmalloc is as basic as folio.
vmalloc() ultimately calls vm_area_alloc_pages() -> alloc_pages_bulk_node_noprof()
KHO should have functions that clearly pair with the low level
allocators struct page related allocators, alloc_pages(order),
folio_alloc(), etc etc
ie if you call this allocator X then you call this kho preserve, this
kho restore, and this free function Y.
Under the covers it all uses the generic folio based code we already
have, but we should have appropriate wrappers around that code that
make clear these patterns.
Jason
Powered by blists - more mailing lists