Re: [PATCH v6 06/16] libs/call: cache up to 4 pages in hypercall bounce buffers

[Anthony PERARD <anthony.perard@xxxxxxxxxx>]

On Tue, Jul 07, 2026 at 03:51:40PM +0200, Anthony PERARD wrote:
> On Fri, Jun 19, 2026 at 02:04:51PM +0100, Frediano Ziglio wrote:
> > From: Edwin Török <edwin.torok@xxxxxxxxxx>
> > 
> > During migration there are a lot of mmap/munmap calls,
> > because `xc_get_pfn_type_batch` exceeds the default hypercall bounce
> > buffer cache size, and needs to allocate every time it is called.
> 
> I think xc_get_pfn_type_batch() would allocate a buffer of 2 page top,
> in write_batch(), right ?

(because nr_pfns <= MAX_BATCH_SIZE, and we allocate
nr_pfns*sizeof(unsigned  long)

> > `munmap` is slow, especially in a PV Dom0 (takes an emulation fault),
> > so is best avoided.
> > 
> > Eventually it'd be good if the memory pool from  xmalloc_tlsf.c
> > was reused here, but for now make it handle the commonly encountered
> > sizes (so far up to 4 pages).

So do you know what would allocate 4 pages?

In anycase, I guess it's ok to keep an allocation of 160kb
for a short while.

> > diff --git a/tools/libs/call/buffer.c b/tools/libs/call/buffer.c
> > index 155e4f9d43..2f0515c273 100644
> > --- a/tools/libs/call/buffer.c
> > +++ b/tools/libs/call/buffer.c
> > @@ -49,6 +49,9 @@ static void *cache_alloc(xencall_handle *xcall, size_t 
> > nr_pages)
> >  {
> >      void *p = NULL;
> >  
> > +    if ( nr_pages == 0 )
> > +        return NULL;
> 
> By doing that check here, we don't update the stat anymore. And it's
> getting out-of-sync with the updates done in cache_free().
> 
> Before, we where returning a cache entry for that, and cache_hit++. I
> think it's ok to return cache_miss++ instead.
> 

The rest of the patch looks fine to me, and I guess is ok.

(and I send the previous mail a bit too soon)

Thanks,


--
Anthony Perard | Vates XCP-ng Developer

XCP-ng & Xen Orchestra - Vates solutions

web: https://vates.tech