From: Vladimir Sementsov-Ogievskiy via <qemu-devel@nongnu.org>
To: Emanuele Giuseppe Esposito <eesposit@redhat.com>,
Stefan Hajnoczi <stefanha@redhat.com>
Cc: qemu-block@nongnu.org, John Snow <jsnow@redhat.com>,
Kevin Wolf <kwolf@redhat.com>, Max Reitz <mreitz@redhat.com>,
Paolo Bonzini <pbonzini@redhat.com>,
qemu-devel@nongnu.org
Subject: Re: [PATCH 5/6] co-shared-resource: protect with a mutex
Date: Sat, 15 May 2021 10:11:38 +0300 [thread overview]
Message-ID: <3db7b2d0-1030-a449-3e4a-4ac9c0ec48eb@virtuozzo.com> (raw)
In-Reply-To: <dc635abd-6beb-863a-6560-1531a0cd5dc6@redhat.com>
15.05.2021 00:53, Emanuele Giuseppe Esposito wrote:
>
>>>>>> 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".
Hm. Understand now. If you go this way, I'd better add a critical section and keep shres operations where they are now. We don't have shres operation in task creation, so should not have in task finalization. Shres operations are kept in seperate. It probably not bad to refactor it to make shres operations as a part of task manipulation functions, but it would require more accurate refactoring, simpler is to keep it as is.
--
Best regards,
Vladimir
next prev parent reply other threads:[~2021-05-15 7:12 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
2021-05-15 7:11 ` Vladimir Sementsov-Ogievskiy via [this message]
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=3db7b2d0-1030-a449-3e4a-4ac9c0ec48eb@virtuozzo.com \
--to=qemu-devel@nongnu.org \
--cc=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=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.