qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: John Snow <jsnow@redhat.com>
To: Eduardo Habkost <ehabkost@redhat.com>
Cc: "Huacai Chen" <chenhuacai@kernel.org>,
	qemu-devel <qemu-devel@nongnu.org>,
	"Markus Armbruster" <armbru@redhat.com>,
	"Gerd Hoffmann" <kraxel@redhat.com>,
	"Philippe Mathieu-Daudé" <f4bug@amsat.org>
Subject: Re: [PATCH] via-ide: Avoid expensive operations in irq handler
Date: Wed, 20 Oct 2021 12:32:42 -0400	[thread overview]
Message-ID: <CAFn=p-YxcDADgfsrHdb1pNgreLmsLO1r2uSwMRC4BdLJLvA2pw@mail.gmail.com> (raw)
In-Reply-To: <20211020151824.ecl3etam425diyli@habkost.net>

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

On Wed, Oct 20, 2021 at 11:18 AM Eduardo Habkost <ehabkost@redhat.com>
wrote:

> On Wed, Oct 20, 2021 at 04:58:58PM +0200, BALATON Zoltan wrote:
> > On Wed, 20 Oct 2021, Eduardo Habkost wrote:
> > > On Mon, Oct 18, 2021 at 12:10:04PM +0200, Philippe Mathieu-Daudé wrote:
> > > > On 10/18/21 11:51, BALATON Zoltan wrote:
> > > > > On Mon, 18 Oct 2021, Philippe Mathieu-Daudé wrote:
> > > > > > On 10/18/21 03:36, BALATON Zoltan wrote:
> > > > > > > Cache the pointer to PCI function 0 (ISA bridge, that this IDE
> device
> > > > > > > has to use for IRQs) in the PCIIDEState and pass that as the
> opaque
> > > > > > > data for the interrupt handler to eliminate both the need to
> look up
> > > > > > > function 0 at every interrupt and also a QOM type cast of the
> opaque
> > > > > > > pointer as that's also expensive (mainly due to qom-debug being
> > > > > > > enabled by default).
> > > > > > >
> > > > > > > Suggested-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
> > > > > > > Signed-off-by: BALATON Zoltan <balaton@eik.bme.hu>
> > > > > > > ---
> > > > > > >  hw/ide/via.c         | 11 ++++++-----
> > > > > > >  include/hw/ide/pci.h |  1 +
> > > > > > >  2 files changed, 7 insertions(+), 5 deletions(-)
> > > > > > >
> > > > > > > diff --git a/hw/ide/via.c b/hw/ide/via.c
> > > > > > > index 82def819c4..30566bc409 100644
> > > > > > > --- a/hw/ide/via.c
> > > > > > > +++ b/hw/ide/via.c
> > > > > > > @@ -104,15 +104,15 @@ static void bmdma_setup_bar(PCIIDEState
> *d)
> > > > > > >
> > > > > > >  static void via_ide_set_irq(void *opaque, int n, int level)
> > > > > > >  {
> > > > > > > -    PCIDevice *d = PCI_DEVICE(opaque);
> > > > > > > +    PCIIDEState *d = opaque;
> > > > > > >
> > > > > > >      if (level) {
> > > > > > > -        d->config[0x70 + n * 8] |= 0x80;
> > > > > > > +        d->parent_obj.config[0x70 + n * 8] |= 0x80;
> > > > > > >      } else {
> > > > > > > -        d->config[0x70 + n * 8] &= ~0x80;
> > > > > > > +        d->parent_obj.config[0x70 + n * 8] &= ~0x80;
> > > > > > >      }
> > > > > >
> > > > > > Better not to access parent_obj, so I'd rather keep the previous
> > > > > > code as it. The rest is OK, thanks. If you don't want to respin
> > > > > > I can fix and take via mips-next.
> > > > >
> > > > > Why not? If it's OK to access other fields why not parent_obj? That
> > > > > avoids the QOM cast PCI_DEVICE(opaque) or PCI_DEVICE(d) after this
> > > > > patch. We know it's a PCIIDEState and has PCIDevice parent_obj
> field
> > > > > because we set the opaque pointer when adding this callback so I
> think
> > > > > this works and is the less expensive way. But feel free to change
> it any
> > > > > way you like and use it that way. I'd keep it as it is.
> > > >
> > > > My understanding of QOM is we shouldn't access internal states that
> > > > way, because 1/ this makes object refactors harder and 2/ this is
> > > > not the style/example we want in the codebase, but it doesn't seem
> > > > documented, so Cc'ing Markus/Eduardo for confirmation.
> > >
> > > `PCI_DEVICE(d)` is preferred instead `of d.parent_obj` (parent_obj is
> > > just a QOM implementation detail).  If there are real performance
> > > reasons to avoid it, we need numbers to support that.
> >
> > OK I can try to do some measurement or go back to PCI_DEVICE() then.
> >
> > > Also, note that `OBJECT_CHECK(obj)` is just `return obj` if
> > > CONFIG_QOM_CAST_DEBUG is disabled.
> >
> > But configure enables it by default even without --enable-debug so I
> think
> > most people don't even know and it's enabled practically everywhere
> > (probably even in distros). Why can't we have it disabled by default if
> it's
> > a developer debug option and enable it only for developers where it's
> useful
> > to catch bugs?
>
> It's a trade-off, I don't think there's a right answer for
> everybody.  Personally, I'd say the benefits outweigh the risks
> of disabling it for most users (especially the ones building QEMU
> directly from source).
>
> I don't mean to say it's OK for CONFIG_QOM_CAST_DEBUG=y builds to
> have visibly poor performance.  If the typecast above causes a
> measurable performance impact, it might be reasonable to have a
> workaround like:
>
>   static void via_ide_set_irq(void *opaque, int n, int level)
>   {
>       PCIIDEState *ide = opaque;
>       PCIDevice *pci = opaque;
>       ...
>   }
>
> --
> Eduardo
>
>
For the record here, I'm going to defer to consensus judgment between
Eduardo, Philippe, and BALATON. Let me know when you're all happy with the
patch.

--js

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

  reply	other threads:[~2021-10-20 16:34 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-10-18  1:36 [PATCH] via-ide: Avoid expensive operations in irq handler BALATON Zoltan
2021-10-18  9:42 ` Philippe Mathieu-Daudé
2021-10-18  9:51   ` BALATON Zoltan
2021-10-18 10:10     ` Philippe Mathieu-Daudé
2021-10-20 14:36       ` Eduardo Habkost
2021-10-20 14:58         ` BALATON Zoltan
2021-10-20 15:18           ` Eduardo Habkost
2021-10-20 16:32             ` John Snow [this message]
2021-10-20 22:58         ` BALATON Zoltan

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='CAFn=p-YxcDADgfsrHdb1pNgreLmsLO1r2uSwMRC4BdLJLvA2pw@mail.gmail.com' \
    --to=jsnow@redhat.com \
    --cc=armbru@redhat.com \
    --cc=chenhuacai@kernel.org \
    --cc=ehabkost@redhat.com \
    --cc=f4bug@amsat.org \
    --cc=kraxel@redhat.com \
    --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).