qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[PATCH 0/2] Update use_goto_tb() in hppa and rx targets


From: Ahmed Karaman
Subject: [PATCH 0/2] Update use_goto_tb() in hppa and rx targets
Date: Tue, 19 May 2020 18:21:42 +0200

Greetings to all QEMU developers!

First of all, I want to say I'm really honored that I will be working
with you on the Google Summer of Code project "TCG Continuous
Benchmarking" this June, July and August.

This is my first set of patches sent to the QEMU mailing list, that
came up as a result of some preliminary exploration for this project.

***

Dear Mr. Richard,

During some performance experiments that Mr. Aleksandar Markovic an I
were doing recently, we discovered a performance drop in the the hppa
target user mode after the commit below:

https://git.qemu.org/?p=qemu.git;a=commit;h=f3b423ec6e

The issue arose because the page crossings check in use_goto_tb()
function is required only in the system mode. Checking it in both modes
causes an unnecessary overhead in the user mode.

The issue can be solved by simply checking for the page crossings only
in the system mode. By doing so, the runtime of the target decreased by
up to 6.93% on some benchmarks that we tested against.

The patch 1/2 proposes such solution for the mentioned problem.

***

Dear Mr. Yoshinori,

For the rx target, the problem is almost the opposite to one described
above for the hppa target problem. The page crossings check in rx's
use_goto_tb() was missing, so I included it to be checked, and, off
course, in the system mode only. Just for the sake of clarity, I added
some other relatively minor improvements to that function. Without this
patch, you may experience intermittent and hard-to-debug bugs while
running rx target in system-mode.

The patch 2/2 proposes the solution for the problem I described.

***

The approach to the "TCG Continuous Benchmarking" project adopted by
Mr. Aleksandar and I can by called "tool-agnostic". This means that we
will not favor any single performance-measurement-related tool, but that
we will consider a wide range of such tools, examine the details of
functionalities they provide, and use the one that fits a given
situation the most.

For performance measurements related to patch 1/2, we utilized a tool
called Valgrind (more precisely, its subtool called Callgrind) - we
measured the performance before and after the fix using it. The reason
for such choice is that this method gave use the most stable results -
the results between subsequent measurements of an identical experiment
had very little differences. That quality was not present in other
tools, or, at least, was not that good for other tools.

We plan to continue such pragmatic approach to tools choice - rather
than fix the preferred tool in advance at the beginning of the project.

For starters, we will present to you a comparison between Perf and
Valgrind/Callgrind tools. To know more on the setup, usage, pros and
cons of each of these tools, keep an eye on the mailing list for a
detailed post that will be sent by myself very soon. It will cover the
basics of what you should know to start integrating these tools in your
development workflow.

Best regards,
Ahmed Karaman

Ahmed Karaman (2):
  target/hppa: Check page crossings in use_goto_tb() only in system mode
  target/rx: Check for page crossings in use_goto_tb()

 target/hppa/translate.c | 18 ++++++++++++++----
 target/rx/translate.c   | 12 ++++++++----
 2 files changed, 22 insertions(+), 8 deletions(-)

-- 
2.17.1




reply via email to

[Prev in Thread] Current Thread [Next in Thread]