Re: [PATCH 1/5] RDMA/umem: ib_umem_get(): use kmalloc() to allocate page array

["Vlastimil Babka (SUSE)" <vbabka@kernel.org>]

On 6/30/26 17:36, Jason Gunthorpe wrote:
> On Tue, Jun 30, 2026 at 06:01:17PM +0300, Mike Rapoport wrote:
>> (actually adding Vlastimil :) )
>> 
>> On Tue, Jun 30, 2026 at 06:00:24PM +0300, Mike Rapoport wrote:
>> > (adding Vlastimil)
>> > 
>> > On Tue, Jun 30, 2026 at 09:31:50AM -0300, Jason Gunthorpe wrote:
>> > > On Tue, Jun 30, 2026 at 01:52:29PM +0300, Mike Rapoport (Microsoft) wrote:
>> > > > ib_umem_get() allocates an array of pointers to struct page for
>> > > > pin_user_pages_fast() calls during memory registration.
>> > > 
>> > > A whole bunch of these use cases in rdma are really "give me some
>> > > temporary memory, I want it fast and as large as possible. In a
>> > > syscall context I will free it before returning back to userspace"
>> > 
>> > Not sure I follow where "as large as possible" comes from. Here it's
>> > explicitly a page.
> 
> It is a page because that is "fast"
> 
> There will be a calculation what the upper limit of memory is that
> this algorithm can use.
> 
>> > And does "fast" mean that vmalloc() is not an option?
> 
> Yes. The trade off is you do fewer iterations of some loop if you have
> a bigger temporary buffer. But if it takes longer to allocate than the loop
> iterations then it doesn't help.
> 
>> > > So, how would you feel about a new API?
>> > > 
>> > >  void *kmalloc_temporary(size_t min_size, size_t max_size, size_t *actual_size, gfp);
>> > > 
>> > > I know of a few other cases like this in the kernel at least.
>> > > 
>> > > The implementation could try to find an available high order page and
>> > > immediately return it, otherwise do a small reclaim allocation?
>> > 
>> > How do you suggest to decide how much of reclaim should happen?
>> > With the usual semantics of gfp?
> 
> Yeah, when all options are exhausted you do some allocation with the
> usual GFP options.

I think this should be discussed more broadly and not block this change.
Instead of adding just kmalloc_temporary() we should look at the bigger
picture where we have manual optimistic nowait attempts with smaller
fallbacks. Willy's LSF/MM plenary touched on this, as well as recent threads
with Dave Chinner [1] etc.

With that said, I'm for example not sure if "_temporary()" is really the
distinguishing characteristic for this to be part of the name.

[1] https://lore.kernel.org/all/1f50ce04-20e6-46a0-9d8a-00a5f7a74967@suse.com/

> Jason