qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [RFC PATCH v3 15/30] io: Add a pwritev/preadv version that takes a d


From: Peter Xu
Subject: Re: [RFC PATCH v3 15/30] io: Add a pwritev/preadv version that takes a discontiguous iovec
Date: Thu, 18 Jan 2024 15:44:27 +0800

On Wed, Jan 17, 2024 at 03:06:15PM -0300, Fabiano Rosas wrote:
> Oh no, you're right. Because of p->pending_job. And thinking about
> p->pending_job, wouldn't a trylock to the same job while being more
> explicit?
> 
>     next_channel %= migrate_multifd_channels();
>     for (i = next_channel;; i = (i + 1) % migrate_multifd_channels()) {
>         p = &multifd_send_state->params[i];
> 
>         if(qemu_mutex_trylock(&p->mutex)) {
>             if (p->quit) {
>                 error_report("%s: channel %d has already quit!", __func__, i);
>                 qemu_mutex_unlock(&p->mutex);
>                 return -1;
>             }
>             next_channel = (i + 1) % migrate_multifd_channels();
>             break;
>         } else {
>             /* channel still busy, try the next one */
>         }
>     }
>     multifd_send_state->pages = p->pages;
>     p->pages = pages;
>     qemu_mutex_unlock(&p->mutex);

We probably can't for now; multifd_send_thread() will unlock the mutex
before the iochannel write()s, while the write()s will need those fields.

> Ok, then I can take block->pages_offset and block->host from the
> ramblock. I think I prefer something like this, that way we can be
> explicit about the migration assumptions.

I'm glad we reached an initial consensus.  Yes let's put that in
migration/; I won't expect this code will be used by other iochannel users.

-- 
Peter Xu




reply via email to

[Prev in Thread] Current Thread [Next in Thread]