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

[Jason Gunthorpe]

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.

Jason