All of lore.kernel.org
 help / color / mirror / Atom feed
From: Kevin Wolf <kwolf@redhat.com>
To: "Denis V. Lunev" <den@openvz.org>
Cc: Denis Plotnikov <dplotnikov@virtuozzo.com>,
	mreitz@redhat.com, stefanha@redhat.com, vsementsov@virtuozzo.com,
	famz@redhat.com, qemu-stable@nongnu.org, qemu-block@nongnu.org,
	qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [PATCH v0 2/2] block: postpone the coroutine executing if the BDS's is drained
Date: Thu, 13 Sep 2018 10:44:50 +0200	[thread overview]
Message-ID: <20180913084450.GA5172@localhost.localdomain> (raw)
In-Reply-To: <5706f9f2-386f-aca9-4b7d-9fb924c68a7e@openvz.org>

Am 12.09.2018 um 19:03 hat Denis V. Lunev geschrieben:
> On 09/12/2018 04:15 PM, Kevin Wolf wrote:
> > Am 12.09.2018 um 14:03 hat Denis Plotnikov geschrieben:
> >> On 10.09.2018 15:41, Kevin Wolf wrote:
> >>> Am 29.06.2018 um 14:40 hat Denis Plotnikov geschrieben:
> >>>> Fixes the problem of ide request appearing when the BDS is in
> >>>> the "drained section".
> >>>>
> >>>> Without the patch the request can come and be processed by the main
> >>>> event loop, as the ide requests are processed by the main event loop
> >>>> and the main event loop doesn't stop when its context is in the
> >>>> "drained section".
> >>>> The request execution is postponed until the end of "drained section".
> >>>>
> >>>> The patch doesn't modify ide specific code, as well as any other
> >>>> device code. Instead, it modifies the infrastructure of asynchronous
> >>>> Block Backend requests, in favor of postponing the requests arisen
> >>>> when in "drained section" to remove the possibility of request appearing
> >>>> for all the infrastructure clients.
> >>>>
> >>>> This approach doesn't make vCPU processing the request wait untill
> >>>> the end of request processing.
> >>>>
> >>>> Signed-off-by: Denis Plotnikov <dplotnikov@virtuozzo.com>
> >>> I generally agree with the idea that requests should be queued during a
> >>> drained section. However, I think there are a few fundamental problems
> >>> with the implementation in this series:
> >>>
> >>> 1) aio_disable_external() is already a layering violation and we'd like
> >>>     to get rid of it (by replacing it with a BlockDevOps callback from
> >>>     BlockBackend to the devices), so adding more functionality there
> >>>     feels like a step in the wrong direction.
> >>>
> >>> 2) Only blk_aio_* are fixed, while we also have synchronous public
> >>>     interfaces (blk_pread/pwrite) as well as coroutine-based ones
> >>>     (blk_co_*). They need to be postponed as well.
> >> Good point! Thanks!
> 
> Should we really prohibit all public interfaces, as they are reused
> inside block level?

We need to fix that. blk_*() should never be called from inside the BDS
layer.

> There is also a problem which is not stated in the clear words yet.
> We have potential deadlock in the code under the following
> conditions, which should be also taken into the consideration.
> 
> <path from the controller>
> bdrv_co_pwritev
>     bdrv_inc_in_flight
>     bdrv_aligned_pwritev
>         notifier_list_with_return_notify
>              backup_before_write_notify
>                  backup_do_cow
>                      backup_cow_with_bounce_buffer
>                          blk_co_preadv
> 
> Here blk_co_preadv() must finish its work before we will release the
> notifier and finish request initiated from the controller and which
> has incremented in-fligh counter.

Yes, before_write notifiers are evil. I've objected to them since the
day they were introduced and I'm surprised it's becoming a problem only
now.

We should probably change the backup job to insert a job node rather
sooner than later. Then it doesn't need to call blk_*() any more.

> Thus we should differentiate requests initiated at the controller
> level and requests initiated in the block layer.  This is sad but
> true.

The difference is supposed to be whether a request goes through a
BlockBackend or not.

Kevin

  reply	other threads:[~2018-09-13  8:45 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-06-29 12:40 [Qemu-devel] [PATCH v0 0/2] Postponed actions Denis Plotnikov
2018-06-29 12:40 ` [Qemu-devel] [PATCH v0 1/2] async: add infrastructure for postponed actions Denis Plotnikov
2018-06-29 12:40 ` [Qemu-devel] [PATCH v0 2/2] block: postpone the coroutine executing if the BDS's is drained Denis Plotnikov
2018-09-10 12:41   ` Kevin Wolf
2018-09-12 12:03     ` Denis Plotnikov
2018-09-12 13:15       ` Kevin Wolf
2018-09-12 14:53         ` Denis Plotnikov
2018-09-12 15:09           ` Kevin Wolf
2018-09-12 17:03         ` Denis V. Lunev
2018-09-13  8:44           ` Kevin Wolf [this message]
2018-07-02  1:47 ` [Qemu-devel] [PATCH v0 0/2] Postponed actions no-reply
2018-07-02 15:18 ` [Qemu-devel] [Qemu-block] " Stefan Hajnoczi
2018-07-17 10:31   ` Stefan Hajnoczi
2018-07-16 15:01 ` [Qemu-devel] " Denis Plotnikov
2018-07-16 18:59   ` [Qemu-devel] [Qemu-block] " John Snow
2018-07-18  7:53     ` Denis Plotnikov
2018-08-13  8:32     ` Denis Plotnikov
2018-08-13 16:30       ` Kevin Wolf
2018-08-14  7:08         ` Denis Plotnikov
2018-08-20  7:40           ` Denis Plotnikov
2018-08-20  7:42           ` Denis Plotnikov
2018-08-27  7:05           ` Denis Plotnikov
2018-08-27 16:05             ` John Snow
2018-08-28 10:23               ` Denis Plotnikov
2018-09-10 10:11                 ` 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=20180913084450.GA5172@localhost.localdomain \
    --to=kwolf@redhat.com \
    --cc=den@openvz.org \
    --cc=dplotnikov@virtuozzo.com \
    --cc=famz@redhat.com \
    --cc=mreitz@redhat.com \
    --cc=qemu-block@nongnu.org \
    --cc=qemu-devel@nongnu.org \
    --cc=qemu-stable@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.