From: Peter Maydell <peter.maydell@linaro.org>
To: Idan Horowitz <idan.horowitz@gmail.com>
Cc: qemu-arm@nongnu.org, qemu-devel@nongnu.org
Subject: Re: [PATCH] target/arm: Allow only specific instructions based on the SCTLR_EL1.UCI bit
Date: Thu, 20 Jan 2022 14:16:45 +0000 [thread overview]
Message-ID: <CAFEAcA-Vdhh-soGuQfUh0kB0SJovKa9BPbHSRC6wHsU8gDczTA@mail.gmail.com> (raw)
In-Reply-To: <CA+4MfE+EGpnXn5WHwCgT+-bE7u7ZOdNqK2bjenuheoskFZqSMw@mail.gmail.com>
On Thu, 20 Jan 2022 at 13:25, Idan Horowitz <idan.horowitz@gmail.com> wrote:
>
> On Thu, 20 Jan 2022 at 14:32, Peter Maydell <peter.maydell@linaro.org> wrote:
> >
> >
> > But the code you are effectively removing is never executed
> > for the instructions where you're changing the access function.
> > If you're proposing this as a performance improvement, can
> > you provide before-and-after benchmarks demonstrating that
> > improvement ?
> >
>
> I wanted to say that in my micro-benchmark of DC IVAC I saw a 1%
> decrease in runtime, but I failed to replicate it again now, so I must
> have accidentally ran it together with one of my other patches last
> time.
> Sorry for wasting your time with the review.
No worries.
Incidentally, it's not surprising that if you microbenchmark
the cache instructions the trap-checking appears as a large
component of it -- for QEMU cache ops are NOPs so trap checking
is the *only* thing that the instruction has to do. It's probably
worth looking at benchmarks of real workloads to try to identify
whether any particular instruction is a significant component
before spending much time on trying to improve its performance.
-- PMM
prev parent reply other threads:[~2022-01-20 19:14 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-01-14 0:40 [PATCH] target/arm: Allow only specific instructions based on the SCTLR_EL1.UCI bit Idan Horowitz
2022-01-20 11:42 ` Peter Maydell
2022-01-20 12:00 ` Idan Horowitz
2022-01-20 12:32 ` Peter Maydell
2022-01-20 13:24 ` Idan Horowitz
2022-01-20 14:16 ` Peter Maydell [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=CAFEAcA-Vdhh-soGuQfUh0kB0SJovKa9BPbHSRC6wHsU8gDczTA@mail.gmail.com \
--to=peter.maydell@linaro.org \
--cc=idan.horowitz@gmail.com \
--cc=qemu-arm@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).