qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Vladimir Sementsov-Ogievskiy <v.sementsov-og@mail.ru>
To: Hanna Reitz <hreitz@redhat.com>,
	Vladimir Sementsov-Ogievskiy
	<vladimir.sementsov-ogievskiy@openvz.org>,
	qemu-block@nongnu.org
Cc: qemu-devel@nongnu.org, armbru@redhat.com, eblake@redhat.com,
	stefanha@redhat.com, kwolf@redhat.com, jsnow@redhat.com,
	vsementsov@openvz.org
Subject: Re: [PATCH v2 5/7] block/block-copy: block_copy(): add timeout_ns parameter
Date: Fri, 1 Apr 2022 19:08:53 +0300	[thread overview]
Message-ID: <aa2e58e0-412b-161b-4f66-52d65a5bfd2f@mail.ru> (raw)
In-Reply-To: <929f2a0d-e3d7-afad-b95b-d7f8b29fe077@redhat.com>

01.04.2022 16:16, Hanna Reitz wrote:
> On 01.04.22 11:19, Vladimir Sementsov-Ogievskiy wrote:
>> Add possibility to limit block_copy() call in time. To be used in the
>> next commit.
>>
>> Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@openvz.org>
>> ---
>>   block/block-copy.c         | 26 +++++++++++++++++++-------
>>   block/copy-before-write.c  |  2 +-
>>   include/block/block-copy.h |  2 +-
>>   3 files changed, 21 insertions(+), 9 deletions(-)
>>
>> diff --git a/block/block-copy.c b/block/block-copy.c
>> index ec46775ea5..b47cb188dd 100644
>> --- a/block/block-copy.c
>> +++ b/block/block-copy.c
> 
> [...]
> 
>> @@ -894,12 +902,16 @@ int coroutine_fn block_copy(BlockCopyState *s, int64_t start, int64_t bytes,
>>           .max_workers = BLOCK_COPY_MAX_WORKERS,
>>       };
>> -    return block_copy_common(&call_state);
>> -}
>> +    ret = qemu_co_timeout(block_copy_async_co_entry, call_state, timeout_ns,
>> +                          g_free);
> 
> A direct path for timeout_ns == 0 might still be nice to have.
> 
>> +    if (ret < 0) {
>> +        /* Timeout. call_state will be freed by running coroutine. */
> 
> Maybe assert(ret == -ETIMEDOUT);?

OK

> 
>> +        return ret;
> 
> If I’m right in understanding how qemu_co_timeout() works, block_copy_common() will continue to run here.  Shouldn’t we at least cancel it by setting call_state->cancelled to true?

Agree

> 
> (Besides this, I think that letting block_copy_common() running in the background should be OK.  I’m not sure what the implications are if we do cancel the call here, while on-cbw-error is break-guest-write, though.  Should be fine, I guess, because block_copy_common() will still correctly keep track of what it has successfully copied and what it hasn’t?)

Hmm. I now think, that we should at least wait for such cancelled background requests before block_copy_state_free in cbw_close(). But in "[PATCH v5 00/45] Transactional block-graph modifying API" I want to detach children from CBW filter before calling .close().. So, possible solution is to wait for all cancelled requests on .bdrv_co_drain_begin().

Or alternatively, may be just increase bs->in_flight for CBW filter for each background cancelled request? And decrease when it finish. For this we should add a kind of callback to be called when timed-out coroutine entry finish.

> 
>> +    }
>> -static void coroutine_fn block_copy_async_co_entry(void *opaque)
>> -{
>> -    block_copy_common(opaque);
>> +    ret = call_state->ret;
>> +
>> +    return ret;
> 
> But here we still need to free call_state, right?
> 
>>   }
>>   BlockCopyCallState *block_copy_async(BlockCopyState *s,
> 


-- 
Best regards,
Vladimir


  parent reply	other threads:[~2022-04-01 16:10 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-04-01  9:19 [PATCH v2 0/7] copy-before-write: on-cbw-error and cbw-timeout Vladimir Sementsov-Ogievskiy
2022-04-01  9:19 ` [PATCH v2 1/7] block/copy-before-write: refactor option parsing Vladimir Sementsov-Ogievskiy
2022-04-01 10:50   ` Hanna Reitz
2022-04-01 11:59     ` Vladimir Sementsov-Ogievskiy
2022-04-01  9:19 ` [PATCH v2 2/7] block/copy-before-write: add on-cbw-error open parameter Vladimir Sementsov-Ogievskiy
2022-04-01 11:58   ` Hanna Reitz
2022-04-01 12:18     ` Vladimir Sementsov-Ogievskiy
2022-04-01  9:19 ` [PATCH v2 3/7] iotests: add copy-before-write: on-cbw-error tests Vladimir Sementsov-Ogievskiy
2022-04-01 13:36   ` Hanna Reitz
2022-04-01  9:19 ` [PATCH v2 4/7] util: add qemu-co-timeout Vladimir Sementsov-Ogievskiy
2022-04-01 13:13   ` Hanna Reitz
2022-04-01 14:23     ` Vladimir Sementsov-Ogievskiy
2022-04-01  9:19 ` [PATCH v2 5/7] block/block-copy: block_copy(): add timeout_ns parameter Vladimir Sementsov-Ogievskiy
2022-04-01 13:16   ` Hanna Reitz
2022-04-01 13:22     ` Hanna Reitz
2022-04-01 16:08     ` Vladimir Sementsov-Ogievskiy [this message]
2022-04-04 14:39       ` Hanna Reitz
2022-04-05 11:33         ` Vladimir Sementsov-Ogievskiy
2022-04-06 16:10     ` Vladimir Sementsov-Ogievskiy
2022-04-01  9:19 ` [PATCH v2 6/7] block/copy-before-write: implement cbw-timeout option Vladimir Sementsov-Ogievskiy
2022-04-01 13:24   ` Hanna Reitz
2022-04-01 13:28     ` Hanna Reitz
2022-04-01 13:58       ` Vladimir Sementsov-Ogievskiy
2022-04-01  9:19 ` [PATCH v2 7/7] iotests: copy-before-write: add cases for " Vladimir Sementsov-Ogievskiy
2022-04-01 13:36   ` Hanna Reitz
2022-04-01 13:59     ` Vladimir Sementsov-Ogievskiy

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=aa2e58e0-412b-161b-4f66-52d65a5bfd2f@mail.ru \
    --to=v.sementsov-og@mail.ru \
    --cc=armbru@redhat.com \
    --cc=eblake@redhat.com \
    --cc=hreitz@redhat.com \
    --cc=jsnow@redhat.com \
    --cc=kwolf@redhat.com \
    --cc=qemu-block@nongnu.org \
    --cc=qemu-devel@nongnu.org \
    --cc=stefanha@redhat.com \
    --cc=vladimir.sementsov-ogievskiy@openvz.org \
    --cc=vsementsov@openvz.org \
    /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).