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: Wed, 20 Oct 2021 16:58:58 +0200 (CEST) [thread overview]
Message-ID: <b1447f19-7bb3-c070-abd9-bfcc7c94aa84@eik.bme.hu> (raw)
In-Reply-To: <20211020143626.dvthmwizsljuwqz4@habkost.net>
[-- Attachment #1: Type: text/plain, Size: 3248 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.
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?
Regards,
BALATON Zoltan
next prev parent reply other threads:[~2021-10-20 15:04 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 [this message]
2021-10-20 15:18 ` Eduardo Habkost
2021-10-20 16:32 ` John Snow
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=b1447f19-7bb3-c070-abd9-bfcc7c94aa84@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).