qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Hanna Czenczek <hreitz@redhat.com>
To: Paolo Bonzini <pbonzini@redhat.com>, qemu-block@nongnu.org
Cc: qemu-devel@nongnu.org, Fiona Ebner <f.ebner@proxmox.com>,
	John Snow <jsnow@redhat.com>, Kevin Wolf <kwolf@redhat.com>
Subject: Re: [PATCH for-8.0] ide: Fix manual in-flight count for TRIM BH
Date: Thu, 9 Mar 2023 13:31:35 +0100	[thread overview]
Message-ID: <7ca18cb4-eeb1-4cba-feea-90f28fb9c2fc@redhat.com> (raw)
In-Reply-To: <CABgObfZkSt6-0-vKkUtiWUy1TtHS_kEiYM2wRh+MfjTXmW497A@mail.gmail.com>

On 09.03.23 13:08, Paolo Bonzini wrote:
> On Thu, Mar 9, 2023 at 1:05 PM Paolo Bonzini <pbonzini@redhat.com> wrote:
>> I think having to do this is problematic, because the blk_drain should
>> leave no pending operation.
>>
>> Here it seems okay because you do it in a controlled situation, but the
>> main thread can also issue blk_drain(), or worse bdrv_drained_begin(),
>> and there would be pending I/O operations when it returns.

Not really.  We would stop in the middle of a trim that processes a list 
of discard requests.  So I see it more like stopping in the middle of 
anything that processes guest requests.  Once drain ends, we continue 
processing them, and that’s not exactly pending I/O.

There is a pending object in s->bus->dma->aiocb on the IDE side, so 
there is a pending DMA operation, but naïvely, I don’t see that as a 
problem.

>> Unfortunately I don't have a solution (I'm not considering the idea of
>> using disable_request_queuing and having even more atomics magic in
>> block/block-backend.c), but I'll read the thread.

I wouldn’t disable request queuing, because its introducing commit 
message (cf3129323f900ef5ddbccbe86e4fa801e88c566e) specifically says it 
fixes IDE.  I suppose the reason might actually be this problem here, in 
that before request queuing, it was possible that IDE would continue 
issuing discard requests even while drained, because processing the list 
didn’t stop.  Maybe.

Or the issue is generally that IDE uses dma_* functions, which might 
cause I/O functions to be run from new BHs (I guess through 
reschedule_dma()?).

> Hmm, what about making blk_aio_prwv non-static and calling
> bdrv_co_pdiscard directly from IDE?

You mean transforming ide_issue_trim_cb() into an iterative coroutine 
(instead of being recursive and using AIO) and invoking it via 
blk_aio_prwv()?

It doesn’t feel right to call a bdrv_* function directly from a user 
external to the core block layer, so in this case I’d rather fall back 
to Fiona’s idea of invoking all discards concurrently.

Hanna



  reply	other threads:[~2023-03-09 12:32 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-03-09 11:44 [PATCH for-8.0] ide: Fix manual in-flight count for TRIM BH Hanna Czenczek
2023-03-09 12:05 ` Paolo Bonzini
2023-03-09 12:08   ` Paolo Bonzini
2023-03-09 12:31     ` Hanna Czenczek [this message]
2023-03-09 13:59       ` Paolo Bonzini
2023-03-09 17:46         ` Kevin Wolf
2023-03-10 13:05           ` Fiona Ebner
2023-03-10 14:25             ` Kevin Wolf
2023-03-10 15:13               ` Paolo Bonzini
2023-03-13 12:29                 ` Fiona Ebner
2023-03-13 13:09                   ` Paolo Bonzini
2023-03-13 16:32                 ` Kevin Wolf
2023-03-14  9:42                   ` Paolo Bonzini

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=7ca18cb4-eeb1-4cba-feea-90f28fb9c2fc@redhat.com \
    --to=hreitz@redhat.com \
    --cc=f.ebner@proxmox.com \
    --cc=jsnow@redhat.com \
    --cc=kwolf@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=qemu-block@nongnu.org \
    --cc=qemu-devel@nongnu.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).