qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Denis Plotnikov <dplotnikov@virtuozzo.com>
To: Kevin Wolf <kwolf@redhat.com>
Cc: "keith.busch@intel.com" <keith.busch@intel.com>,
	"jsnow@redhat.com" <jsnow@redhat.com>,
	"qemu-block@nongnu.org" <qemu-block@nongnu.org>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	"mreitz@redhat.com" <mreitz@redhat.com>,
	"stefanha@redhat.com" <stefanha@redhat.com>,
	Denis Lunev <den@virtuozzo.com>,
	"famz@redhat.com" <famz@redhat.com>,
	Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
Subject: Re: [Qemu-devel] [PATCH] blk: postpone request execution on a context protected with "drained section"
Date: Thu, 13 Dec 2018 11:07:55 +0000	[thread overview]
Message-ID: <d0d2cab4-2157-1f9f-3bc9-a70f28a211b0@virtuozzo.com> (raw)
In-Reply-To: <20181212122457.GB5415@linux.fritz.box>



On 12.12.2018 15:24, Kevin Wolf wrote:
> Am 11.12.2018 um 17:55 hat Denis Plotnikov geschrieben:
>>> Why involve the AioContext at all? This could all be kept at the
>>> BlockBackend level without extending the layering violation that
>>> aio_disable_external() is.
>>>
>>> BlockBackends get notified when their root node is drained, so hooking
>>> things up there should be as easy, if not even easier than in
>>> AioContext.
>>
>> Just want to make sure that I understood correctly what you meant by
>> "BlockBackends get notified". Did you mean that bdrv_drain_end calls
>> child's role callback blk_root_drained_end by calling
>> bdrv_parent_drained_end?
> 
> Yes, blk_root_drained_begin/end calls are all you need. Specifically,
> their adjustments to blk->quiesce_counter that are already there, and in
> the 'if (--blk->quiesce_counter == 0)' block of blk_root_drained_end()
> we can resume the queued requests.
Sounds it should be so, but it doesn't work that way and that's why:
when doing mirror we may resume postponed coroutines too early when the 
underlying bs is protected from writing at and thus we encounter the 
assert on a write request execution at bdrv_co_write_req_prepare when 
resuming the postponed coroutines.

The thing is that the bs is protected for writing before execution of 
bdrv_replace_node at mirror_exit_common and bdrv_replace_node calls 
bdrv_replace_child_noperm which, in turn, calls child->role->drained_end 
where one of the callbacks is blk_root_drained_end which check 
if(--blk->quiesce_counter == 0) and runs the postponed requests 
(coroutines) if the coundition is true.

In seems that if the external requests disabled on the context we can't 
rely on anything or should check where the underlying bs and its 
underlying nodes are ready to receive requests which sounds quite 
complicated.
Please correct me if still don't understand something in that routine.

Denis
>> In case if it's so, it won't work if resume postponed requests in
>> blk_root_drained_end since we can't know if external is disabled for the
>> context because the counter showing that is decreased only after roles'
>> drained callbacks are finished at bdrv_do_drained_end.
>> Please correct me if I'm wrong.
> 
> You don't need to know about the AioContext state, this is the whole
> point. blk->quiesce_counter is what tells you whether to postpone
> requests.
> 
>> Looking at the patch again, I think that it might be useful to keep the
>> requests in the structure that limits their execution and also protects
>> the access (context acquire/release) although it's indeed the layering
>> violation but at least we can store the parts related at the same place
>> and later on move somewhere else alongside the request restrictor.
> 
> You can keep everything you need in BlockBackend (and that's also where
> your code is that really postpones request).
> 
> Kevin
> 

-- 
Best,
Denis

  reply	other threads:[~2018-12-13 11:08 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-12-05 12:23 [Qemu-devel] [PATCH] blk: postpone request execution on a context protected with "drained section" Denis Plotnikov
2018-12-07 12:26 ` Kevin Wolf
2018-12-10 12:14   ` Denis Plotnikov
2018-12-10 12:25     ` Kevin Wolf
2018-12-11 16:55   ` Denis Plotnikov
2018-12-12 12:24     ` Kevin Wolf
2018-12-13 11:07       ` Denis Plotnikov [this message]
2018-12-13 12:20         ` Kevin Wolf
2018-12-14 11:54           ` Denis Plotnikov
2018-12-18  8:53             ` Denis Plotnikov
2019-01-09  8:18               ` Denis Plotnikov
2019-01-15  7:22                 ` Denis Plotnikov
2019-01-17 12:57                   ` [Qemu-devel] PING: " Denis Plotnikov
2019-01-17 14:23                     ` Kevin Wolf
2019-01-18  7:43                       ` Denis Plotnikov
     [not found]             ` <20190313160412.GF5167@linux.fritz.box>
2019-04-02  8:35               ` [Qemu-devel] " Denis Plotnikov
2019-04-09 10:01                 ` Kevin Wolf
2019-04-09 10:01                   ` Kevin Wolf
2019-06-21  9:16                   ` [Qemu-devel] [Qemu-block] " Kevin Wolf
2019-06-21  9:59                     ` Vladimir Sementsov-Ogievskiy
2019-06-24  9:46                       ` Denis Plotnikov
2019-06-26  8:46                         ` Denis Plotnikov
2019-06-28 12:32                           ` Kevin Wolf
2019-07-02 14:41                             ` Denis Plotnikov

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=d0d2cab4-2157-1f9f-3bc9-a70f28a211b0@virtuozzo.com \
    --to=dplotnikov@virtuozzo.com \
    --cc=den@virtuozzo.com \
    --cc=famz@redhat.com \
    --cc=jsnow@redhat.com \
    --cc=keith.busch@intel.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).