qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Paolo Bonzini <pbonzini@redhat.com>
To: Emanuele Giuseppe Esposito <eesposit@redhat.com>
Cc: Kevin Wolf <kwolf@redhat.com>,
	Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>,
	"open list:Block layer core" <qemu-block@nongnu.org>,
	qemu-devel <qemu-devel@nongnu.org>, Max Reitz <mreitz@redhat.com>,
	Stefan Hajnoczi <stefanha@redhat.com>,
	John Snow <jsnow@redhat.com>
Subject: Re: [PATCH 5/6] co-shared-resource: protect with a mutex
Date: Fri, 14 May 2021 19:55:25 +0200	[thread overview]
Message-ID: <CABgObfamNZ_2XNHKgEBKXs0XjvhBXnqMVq6jYj+WDojBkJ9cDw@mail.gmail.com> (raw)
In-Reply-To: <6d1e432e-f18a-39a4-0bb6-2a14347c2905@redhat.com>

[-- Attachment #1: Type: text/plain, Size: 3718 bytes --]

Il ven 14 mag 2021, 16:10 Emanuele Giuseppe Esposito <eesposit@redhat.com>
ha scritto:

> > I'm not sure I like it since callers may still need coarser grained
> > locks to protect their own state or synchronize access to multiple
> > items of data. Also, some callers may not need thread-safety.
> >
> > Can the caller to be responsible for locking instead (e.g. using
> > CoMutex)?
>
> Right now co-shared-resource is being used only by block-copy, so I
> guess locking it from the caller or within the API won't really matter
> in this case.
>
> One possible idea on how to delegate this to the caller without adding
> additional small lock/unlock in block-copy is to move co_get_from_shres
> in block_copy_task_end, and calling it only when a boolean passed to
> block_copy_task_end is true.
>

The patch below won't work because qemu_co_queue_wait would have to unlock
the CoMutex; therefore you would have to pass it as an additional argument
to co_get_from_shres.

Overall, neither co_get_from_shres not AioTaskPool should be fast paths, so
using a local lock seems to produce the simplest API.

Paolo


> Otherwise make b_c_task_end always call co_get_from_shres and then
> include co_get_from_shres in block_copy_task_create, so that we always
> add and in case remove (if error) in the shared resource.
>
> Something like:
>
> diff --git a/block/block-copy.c b/block/block-copy.c
> index 3a447a7c3d..1e4914b0cb 100644
> --- a/block/block-copy.c
> +++ b/block/block-copy.c
> @@ -233,6 +233,7 @@ static coroutine_fn BlockCopyTask
> *block_copy_task_create(BlockCopyState *s,
>       /* region is dirty, so no existent tasks possible in it */
>       assert(!find_conflicting_task(s, offset, bytes));
>       QLIST_INSERT_HEAD(&s->tasks, task, list);
> +    co_get_from_shres(s->mem, task->bytes);
>       qemu_co_mutex_unlock(&s->tasks_lock);
>
>       return task;
> @@ -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);
> +    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,
> @@ -379,7 +381,6 @@ static coroutine_fn int
> block_copy_task_run(AioTaskPool *pool,
>
>       aio_task_pool_wait_slot(pool);
>       if (aio_task_pool_status(pool) < 0) {
> -        co_put_to_shres(task->s->mem, task->bytes);
>           block_copy_task_end(task, -ECANCELED);
>           g_free(task);
>           return -ECANCELED;
> @@ -498,7 +499,6 @@ static coroutine_fn int
> block_copy_task_entry(AioTask *task)
>       }
>       qemu_mutex_unlock(&t->s->calls_lock);
>
> -    co_put_to_shres(t->s->mem, t->bytes);
>       block_copy_task_end(t, ret);
>
>       return ret;
> @@ -687,8 +687,6 @@ block_copy_dirty_clusters(BlockCopyCallState
> *call_state)
>
>           trace_block_copy_process(s, task->offset);
>
> -        co_get_from_shres(s->mem, task->bytes);
> -
>           offset = task_end(task);
>           bytes = end - offset;
>
>
>
>
> >
> >> diff --git a/util/qemu-co-shared-resource.c
> b/util/qemu-co-shared-resource.c
> >> index 1c83cd9d29..c455d02a1e 100644
> >> --- a/util/qemu-co-shared-resource.c
> >> +++ b/util/qemu-co-shared-resource.c
> >> @@ -32,6 +32,7 @@ struct SharedResource {
> >>       uint64_t available;
> >>
> >>       CoQueue queue;
> >> +    QemuMutex lock;
> >
> > Please add a comment indicating what this lock protects.
> >
> > Thread safety should also be documented in the header file so API users
> > know what to expect.
>
> Will do, thanks.
>
> Emanuele
>
>

[-- Attachment #2: Type: text/html, Size: 5230 bytes --]

  parent reply	other threads:[~2021-05-14 17:56 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
2021-05-14 17:55       ` Paolo Bonzini [this message]
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=CABgObfamNZ_2XNHKgEBKXs0XjvhBXnqMVq6jYj+WDojBkJ9cDw@mail.gmail.com \
    --to=pbonzini@redhat.com \
    --cc=eesposit@redhat.com \
    --cc=jsnow@redhat.com \
    --cc=kwolf@redhat.com \
    --cc=mreitz@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).