* [PATCH] multifd: Fix the number of channels ready
@ 2023-04-26 16:23 Juan Quintela
2023-04-26 17:22 ` Fabiano Rosas
2023-04-26 17:58 ` Fabiano Rosas
0 siblings, 2 replies; 5+ messages in thread
From: Juan Quintela @ 2023-04-26 16:23 UTC (permalink / raw)
To: qemu-devel; +Cc: Peter Xu, Leonardo Bras, Juan Quintela
We don't wait in the sem when we are doing a sync_main. Make it wait
there. To make things clearer, we mark the channel ready at the
begining of the thread loop.
Signed-off-by: Juan Quintela <quintela@redhat.com>
---
migration/multifd.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/migration/multifd.c b/migration/multifd.c
index 903df2117b..e625e8725e 100644
--- a/migration/multifd.c
+++ b/migration/multifd.c
@@ -635,6 +635,7 @@ int multifd_send_sync_main(QEMUFile *f)
for (i = 0; i < migrate_multifd_channels(); i++) {
MultiFDSendParams *p = &multifd_send_state->params[i];
+ qemu_sem_wait(&multifd_send_state->channels_ready);
trace_multifd_send_sync_main_wait(p->id);
qemu_sem_wait(&p->sem_sync);
@@ -668,6 +669,7 @@ static void *multifd_send_thread(void *opaque)
p->num_packets = 1;
while (true) {
+ qemu_sem_post(&multifd_send_state->channels_ready);
qemu_sem_wait(&p->sem);
if (qatomic_read(&multifd_send_state->exiting)) {
@@ -736,7 +738,6 @@ static void *multifd_send_thread(void *opaque)
if (flags & MULTIFD_FLAG_SYNC) {
qemu_sem_post(&p->sem_sync);
}
- qemu_sem_post(&multifd_send_state->channels_ready);
} else if (p->quit) {
qemu_mutex_unlock(&p->mutex);
break;
--
2.40.0
^ permalink raw reply related [flat|nested] 5+ messages in thread
* Re: [PATCH] multifd: Fix the number of channels ready
2023-04-26 16:23 [PATCH] multifd: Fix the number of channels ready Juan Quintela
@ 2023-04-26 17:22 ` Fabiano Rosas
2023-04-26 17:35 ` Juan Quintela
2023-04-26 17:58 ` Fabiano Rosas
1 sibling, 1 reply; 5+ messages in thread
From: Fabiano Rosas @ 2023-04-26 17:22 UTC (permalink / raw)
To: Juan Quintela, qemu-devel; +Cc: Peter Xu, Leonardo Bras, Juan Quintela
Juan Quintela <quintela@redhat.com> writes:
> We don't wait in the sem when we are doing a sync_main. Make it wait
> there. To make things clearer, we mark the channel ready at the
> begining of the thread loop.
So in other words we're estabilishing that "channel ready" means ready
to send, regardless of having sent the sync packet. Is that it?
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH] multifd: Fix the number of channels ready
2023-04-26 17:22 ` Fabiano Rosas
@ 2023-04-26 17:35 ` Juan Quintela
2023-04-26 17:58 ` Fabiano Rosas
0 siblings, 1 reply; 5+ messages in thread
From: Juan Quintela @ 2023-04-26 17:35 UTC (permalink / raw)
To: Fabiano Rosas; +Cc: qemu-devel, Peter Xu, Leonardo Bras
Fabiano Rosas <farosas@suse.de> wrote:
> Juan Quintela <quintela@redhat.com> writes:
>
>> We don't wait in the sem when we are doing a sync_main. Make it wait
>> there. To make things clearer, we mark the channel ready at the
>> begining of the thread loop.
>
> So in other words we're estabilishing that "channel ready" means ready
> to send, regardless of having sent the sync packet. Is that it?
Yeap.
There was a bug (from the beggining) that made the counter always get
up and up. This fixes it.
It was always supposed to work this way.
/me puts (second time in the week) a brown paper bag on head
Later, Juan.
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH] multifd: Fix the number of channels ready
2023-04-26 17:35 ` Juan Quintela
@ 2023-04-26 17:58 ` Fabiano Rosas
0 siblings, 0 replies; 5+ messages in thread
From: Fabiano Rosas @ 2023-04-26 17:58 UTC (permalink / raw)
To: quintela; +Cc: qemu-devel, Peter Xu, Leonardo Bras
Juan Quintela <quintela@redhat.com> writes:
> Fabiano Rosas <farosas@suse.de> wrote:
>> Juan Quintela <quintela@redhat.com> writes:
>>
>>> We don't wait in the sem when we are doing a sync_main. Make it wait
>>> there. To make things clearer, we mark the channel ready at the
>>> begining of the thread loop.
>>
>> So in other words we're estabilishing that "channel ready" means ready
>> to send, regardless of having sent the sync packet. Is that it?
>
> Yeap.
>
> There was a bug (from the beggining) that made the counter always get
> up and up. This fixes it.
>
> It was always supposed to work this way.
Ah, great. I'm proposing a multifd variant without the sync packet in my
fixed-ram series and moving the channels_ready to the top of the loop
means I can stop issuing an extra qemu_sem_post(&p->sem) just to skip
the sync packet.
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH] multifd: Fix the number of channels ready
2023-04-26 16:23 [PATCH] multifd: Fix the number of channels ready Juan Quintela
2023-04-26 17:22 ` Fabiano Rosas
@ 2023-04-26 17:58 ` Fabiano Rosas
1 sibling, 0 replies; 5+ messages in thread
From: Fabiano Rosas @ 2023-04-26 17:58 UTC (permalink / raw)
To: Juan Quintela, qemu-devel; +Cc: Peter Xu, Leonardo Bras, Juan Quintela
Juan Quintela <quintela@redhat.com> writes:
> We don't wait in the sem when we are doing a sync_main. Make it wait
> there. To make things clearer, we mark the channel ready at the
> begining of the thread loop.
>
> Signed-off-by: Juan Quintela <quintela@redhat.com>
Reviewed-by: Fabiano Rosas <farosas@suse.de>
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2023-04-26 17:59 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-04-26 16:23 [PATCH] multifd: Fix the number of channels ready Juan Quintela
2023-04-26 17:22 ` Fabiano Rosas
2023-04-26 17:35 ` Juan Quintela
2023-04-26 17:58 ` Fabiano Rosas
2023-04-26 17:58 ` Fabiano Rosas
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.