[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: |
Fabiano Rosas |
Subject: |
Re: [RFC PATCH v3 15/30] io: Add a pwritev/preadv version that takes a discontiguous iovec |
Date: |
Thu, 18 Jan 2024 09:47:18 -0300 |
Peter Xu <peterx@redhat.com> writes:
> 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.
Right, but we'd change that code to do the IO with the lock held. If no
one is blocking, it should be ok to hold the lock. Anyway, food for
thought.