From: Emanuele Giuseppe Esposito <eesposit@redhat.com>
To: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>,
Stefan Hajnoczi <stefanha@redhat.com>
Cc: Kevin Wolf <kwolf@redhat.com>,
qemu-block@nongnu.org, qemu-devel@nongnu.org,
Max Reitz <mreitz@redhat.com>,
Paolo Bonzini <pbonzini@redhat.com>, John Snow <jsnow@redhat.com>
Subject: Re: [PATCH 5/6] co-shared-resource: protect with a mutex
Date: Fri, 14 May 2021 23:53:26 +0200 [thread overview]
Message-ID: <dc635abd-6beb-863a-6560-1531a0cd5dc6@redhat.com> (raw)
In-Reply-To: <dfb58ab5-a7ea-edf8-5278-6b666aa6097b@virtuozzo.com>
>>>>> we want to get from shres here, after possible call to
>>>>> block_copy_task_shrink(), as task->bytes may be reduced.
>>>>
>>>> Ah right, I missed that. So I guess if we want the caller to protect
>>>> co-shared-resource, get_from_shres stays where it is, and put_
>>>> instead can still go into task_end (with a boolean enabling it).
>>>
>>> honestly, I don't follow how it helps thread-safety
>>
>> From my understanding, the whole point here is to have no lock in
>> co-shared-resource but let the caller take care of it (block-copy).
>>
>> The above was just an idea on how to do it.
>
> But how moving co_put_to_shres() make it thread-safe? Nothing in
> block-copy is thread-safe yet..
>
Sorry this is my bad, I did not explain it properly. If you look closely
at the diff I sent, there are locks in a similar way of my block-copy
initial patch. So I am essentially assuming that block-copy has already
locks, and moving co_put_to_shres in block_copy_task_end has the purpose
of moving shres "in a function that has a critical section".
>>>>>>> @@ -269,6 +270,7 @@ static void coroutine_fn
>>>>>>> block_copy_task_end(BlockCopyTask *task, int ret)
>>>>>>> bdrv_set_dirty_bitmap(task->s->copy_bitmap,
>>>>>>> task->offset, task->bytes);
>>>>>>> }
>>>>>>> qemu_co_mutex_lock(&task->s->tasks_lock);
^^^ locks
>>>>>>> + co_put_to_shres(task->s->mem, task->bytes);
>>>>>>> task->s->in_flight_bytes -= task->bytes;
>>>>>>> QLIST_REMOVE(task, list);
>>>>>>> progress_set_remaining(task->s->progress,
unlocks here (not shown in the diff)
}
Hopefully now it is clear. Apologies again for the confusion.
Emanuele
next prev parent reply other threads:[~2021-05-14 21:54 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-05-10 8:59 [PATCH 0/6] block-copy: make helper APIs thread safe Emanuele Giuseppe Esposito
2021-05-10 8:59 ` [PATCH 1/6] ratelimit: treat zero speed as unlimited Emanuele Giuseppe Esposito
2021-05-10 11:00 ` Vladimir Sementsov-Ogievskiy
2021-05-10 8:59 ` [PATCH 2/6] block-copy: let ratelimit handle a speed of 0 Emanuele Giuseppe Esposito
2021-05-10 11:06 ` Vladimir Sementsov-Ogievskiy
2021-05-10 8:59 ` [PATCH 3/6] blockjob: " Emanuele Giuseppe Esposito
2021-05-10 11:17 ` Vladimir Sementsov-Ogievskiy
2021-05-10 8:59 ` [PATCH 4/6] progressmeter: protect with a mutex Emanuele Giuseppe Esposito
2021-05-10 11:28 ` Vladimir Sementsov-Ogievskiy
2021-05-10 16:52 ` Emanuele Giuseppe Esposito
2021-05-10 17:17 ` Vladimir Sementsov-Ogievskiy
2021-05-10 17:57 ` Emanuele Giuseppe Esposito
2021-05-11 12:28 ` Paolo Bonzini
2021-05-12 7:09 ` Vladimir Sementsov-Ogievskiy
2021-05-12 15:53 ` Stefan Hajnoczi
2021-05-10 8:59 ` [PATCH 5/6] co-shared-resource: " Emanuele Giuseppe Esposito
2021-05-10 11:40 ` Vladimir Sementsov-Ogievskiy
2021-05-11 8:34 ` Paolo Bonzini
2021-05-12 15:44 ` Stefan Hajnoczi
2021-05-12 18:30 ` Paolo Bonzini
2021-05-14 14:10 ` Emanuele Giuseppe Esposito
2021-05-14 14:26 ` Vladimir Sementsov-Ogievskiy via
2021-05-14 14:32 ` Emanuele Giuseppe Esposito
2021-05-14 15:30 ` Vladimir Sementsov-Ogievskiy via
2021-05-14 17:28 ` Emanuele Giuseppe Esposito
2021-05-14 21:15 ` Vladimir Sementsov-Ogievskiy via
2021-05-14 21:53 ` Emanuele Giuseppe Esposito [this message]
2021-05-15 7:11 ` Vladimir Sementsov-Ogievskiy via
2021-05-14 17:55 ` Paolo Bonzini
2021-05-10 8:59 ` [PATCH 6/6] aiopool: " Emanuele Giuseppe Esposito
2021-05-10 11:56 ` Vladimir Sementsov-Ogievskiy
2021-05-11 8:34 ` Paolo Bonzini
2021-05-12 15:19 ` Stefan Hajnoczi
2021-05-10 10:55 ` [PATCH 0/6] block-copy: make helper APIs thread safe Vladimir Sementsov-Ogievskiy
2021-05-12 14:24 ` Stefan Hajnoczi
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=dc635abd-6beb-863a-6560-1531a0cd5dc6@redhat.com \
--to=eesposit@redhat.com \
--cc=jsnow@redhat.com \
--cc=kwolf@redhat.com \
--cc=mreitz@redhat.com \
--cc=pbonzini@redhat.com \
--cc=qemu-block@nongnu.org \
--cc=qemu-devel@nongnu.org \
--cc=stefanha@redhat.com \
--cc=vsementsov@virtuozzo.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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.