Re: [PATCH v2 12/17] migration/multifd: Device state transfer support - send side

[Peter Xu <peterx@redhat.com>]

On Thu, Sep 19, 2024 at 09:49:57PM +0200, Maciej S. Szmigiero wrote:
> On 10.09.2024 18:06, Peter Xu wrote:
> > On Tue, Aug 27, 2024 at 07:54:31PM +0200, Maciej S. Szmigiero wrote:
> > > +bool multifd_queue_device_state(char *idstr, uint32_t instance_id,
> > > +                                char *data, size_t len)
> > > +{
> > > +    /* Device state submissions can come from multiple threads */
> > > +    QEMU_LOCK_GUARD(&queue_job_mutex);
> > 
> > Ah, just notice there's the mutex.
> > 
> > So please consider the reply in the other thread, IIUC we can make it for
> > multifd_send() to be a generic mutex to simplify the other patch too, then
> > drop here.
> > 
> > I assume the ram code should be fine taking one more mutex even without
> > vfio, if it only takes once for each ~128 pages to enqueue, and only take
> > in the main thread, then each update should be also in the hot path
> > (e.g. no cache bouncing).
> > 
> 
> Will check whether it is possible to use a common mutex here for both RAM
> and device state submission without drop in performance.

Thanks.

-- 
Peter Xu