qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: BALATON Zoltan <balaton@eik.bme.hu>
To: Eduardo Habkost <ehabkost@redhat.com>
Cc: "Markus Armbruster" <armbru@redhat.com>,
	"Huacai Chen" <chenhuacai@kernel.org>,
	qemu-devel@nongnu.org, "Philippe Mathieu-Daudé" <f4bug@amsat.org>,
	"Gerd Hoffmann" <kraxel@redhat.com>,
	"John Snow" <jsnow@redhat.com>
Subject: Re: [PATCH] via-ide: Avoid expensive operations in irq handler
Date: Thu, 21 Oct 2021 00:58:20 +0200 (CEST)	[thread overview]
Message-ID: <2313205c-2b0-714-f3bf-718a573fee75@eik.bme.hu> (raw)
In-Reply-To: <20211020143626.dvthmwizsljuwqz4@habkost.net>

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

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.
>
> Also, note that `OBJECT_CHECK(obj)` is just `return obj` if
> CONFIG_QOM_CAST_DEBUG is disabled.

I've tried to do some measurements but could be I did not come up with a 
good enough test (I was just trying to copy a few hundred megabytes and 
timed that) as I could not find any significant difference with or without 
QOM casts or even without this patch (so even caching func0 did not seem 
to make a difference). Could be there are other bigger bottlenecks 
elsewhere before this becomes critical so for now maybe just drop this 
patch and the similar one for USB (that is first and last patch in the 
series) and take the rest of the series only until somebody can do some 
better tests to see if this optimisation would help.

Gerd, Philippe which of you can take care of merging the remaining 
patches? That's still needed to fix USB interrupt on pegasos2.

Regards,
BALATON Zoltan

      parent reply	other threads:[~2021-10-20 23:00 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
2021-10-20 22:58         ` BALATON Zoltan [this message]

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=2313205c-2b0-714-f3bf-718a573fee75@eik.bme.hu \
    --to=balaton@eik.bme.hu \
    --cc=armbru@redhat.com \
    --cc=chenhuacai@kernel.org \
    --cc=ehabkost@redhat.com \
    --cc=f4bug@amsat.org \
    --cc=jsnow@redhat.com \
    --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).