From: Andrii Anisov <andrii.anisov@gmail.com>
To: xen-devel@lists.xen.org
Cc: "Julien Grall" <julien.grall@arm.com>,
"Andrii Anisov" <andrii_anisov@epam.com>,
"Jan Beulich" <JBeulich@suse.com>,
"Roger Pau Monné" <roger.pau@citrix.com>
Subject: [PATCH v2 0/2] Introduce runstate area registration with phys address
Date: Tue, 23 Apr 2019 11:10:24 +0300 [thread overview]
Message-ID: <1556007026-31057-1-git-send-email-andrii.anisov@gmail.com> (raw)
From: Andrii Anisov <andrii_anisov@epam.com>
Following discussion [1] it is introduced and implemented a runstate
registration interface which uses guest's phys address instead of a virtual one.
The new hypercall employes the same data structures as a predecessor, but
expects the vcpu_runstate_info structure to not cross a page boundary.
The interface is implemented in a way vcpu_runstate_info structure is mapped to
the hypervisor on the hypercall processing and is directly accessed during its
updates. This runstate area mapping follows vcpu_info structure registration.
Permanent mapping of runstate area would consume vmap area on arm32 what is
limited to 1G. Though it is assumed that ARM32 does not target the server market
and the rest of possible applications will not host a huge number of VCPUs to
render the limitation into the issue.
The series is tested for ARM64. Build tested for x86. I'd appreciate if someone
could check it with x86.
The Linux kernel patch is here [2]. Though it is for 4.14.
Changes in:
v2: It was reconsidered the new runstate interface implementation. The new
interface is made independent of the old one. Do not share runstate_area
field, and consequently avoid excessive concurrency with the old runstate
interface usage.
Introduced locks in order to resolve possible concurrency between runstate
area registration and usage.
Addressed comments from Jan Beulich [3][4] about coding style nits. Though
some of them become obsolete with refactoring and few are picked into this
thread for further discussion.
There were made performance measurements of approaches (runstate mapped on
access vs mapped on registration). The test setups are as following:
Thin Dom0 (Linux with intiramfs) with DomD running rich Yocto Linux. In
DomD 3d benchmark numbers are compared. The benchmark is GlMark2. GLMark2
is ran with different resolutions in order to emit different irq load,
where 320x240 emits high IRQ load, but 1920x1080 emits low irq load.
Separately tested baking DomD benchmark run with primitive Dom0 CPU burn
(dd), in order to stimulate VCPU(dX)->VCPU(dY) switches rather than
VCPU(dX)->idle->VCPU(dX).
with following results:
mapped mapped
on access on init
GLMark2 320x240 2852 2877 +0.8%
+Dom0 CPUBurn 2088 2094 +0.2%
GLMark2 800x600 2368 2375 +0.3%
+Dom0 CPUBurn 1868 1921 +2.8%
GLMark2 1920x1080 931 931 0%
+Dom0 CPUBurn 892 894 +0.2%
Please note that "mapped on access" means using the old runstate
registering interface. And runstate update in this case still often fails
to map runstate area like [5], despite the fact that our Linux kernel
does not have KPTI enabled. So runstate area update, in this case, is
really shortened.
Also it was checked IRQ latency difference using TBM in a setup similar to
[5]. Please note that the IRQ rate is one in 30 seconds, and only
VCPU->idle->VCPU use-case is considered. With following results (in ns,
the timer granularity 120ns):
mapped on access:
max=9960 warm_max=8640 min=7200 avg=7626
mapped on init:
max=9480 warm_max=8400 min=7080 avg=7341
Unfortunately there are no consitent results yet from profiling using
Lauterbach PowerTrace. Still in communication with the tracer vendor in
order to setup the proper configuration.
[1] https://lists.xenproject.org/archives/html/xen-devel/2019-02/msg00416.html
[2] https://github.com/aanisov/linux/commit/ba34d2780f57ea43f81810cd695aace7b55c0f29
[3] https://lists.xenproject.org/archives/html/xen-devel/2019-03/msg00936.html
[4] https://lists.xenproject.org/archives/html/xen-devel/2019-03/msg00934.html
[5] https://lists.xenproject.org/archives/html/xen-devel/2019-01/msg02369.html
[6] https://lists.xenproject.org/archives/html/xen-devel/2018-12/msg02297.html
Andrii Anisov (2):
xen: introduce VCPUOP_register_runstate_phys_memory_area hypercall
xen: implement VCPUOP_register_runstate_phys_memory_area
xen/arch/arm/domain.c | 62 +++++++++++++++++--------
xen/arch/x86/domain.c | 105 +++++++++++++++++++++++++++++++------------
xen/common/domain.c | 81 +++++++++++++++++++++++++++++++++
xen/include/asm-arm/domain.h | 2 +
xen/include/public/vcpu.h | 15 +++++++
xen/include/xen/domain.h | 2 +
xen/include/xen/sched.h | 8 ++++
7 files changed, 227 insertions(+), 48 deletions(-)
--
2.7.4
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
next reply other threads:[~2019-04-23 8:10 UTC|newest]
Thread overview: 83+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-04-23 8:10 Andrii Anisov [this message]
2019-04-23 8:10 ` [PATCH v2 1/2] xen: introduce VCPUOP_register_runstate_phys_memory_area hypercall Andrii Anisov
2019-04-23 8:10 ` [Xen-devel] " Andrii Anisov
2019-05-08 10:10 ` George Dunlap
2019-05-08 10:10 ` [Xen-devel] " George Dunlap
2019-04-23 8:10 ` [PATCH v2 2/2] xen: implement VCPUOP_register_runstate_phys_memory_area Andrii Anisov
2019-04-23 8:10 ` [Xen-devel] " Andrii Anisov
2019-05-08 15:40 ` Julien Grall
2019-05-08 15:40 ` [Xen-devel] " Julien Grall
2019-05-09 9:27 ` Jan Beulich
2019-05-09 9:27 ` [Xen-devel] " Jan Beulich
2019-05-14 9:35 ` Julien Grall
2019-05-14 9:35 ` [Xen-devel] " Julien Grall
2019-05-14 9:48 ` Jan Beulich
2019-05-14 9:48 ` [Xen-devel] " Jan Beulich
2019-05-14 11:23 ` Julien Grall
2019-05-14 11:23 ` [Xen-devel] " Julien Grall
2019-05-14 11:29 ` Jan Beulich
2019-05-14 11:29 ` [Xen-devel] " Jan Beulich
2019-05-13 12:30 ` Andrii Anisov
2019-05-13 12:30 ` [Xen-devel] " Andrii Anisov
2019-05-14 9:58 ` Julien Grall
2019-05-14 9:58 ` [Xen-devel] " Julien Grall
2019-05-14 10:08 ` Andrii Anisov
2019-05-14 10:08 ` [Xen-devel] " Andrii Anisov
2019-05-14 11:24 ` Julien Grall
2019-05-14 11:24 ` [Xen-devel] " Julien Grall
2019-05-14 11:45 ` Andrii Anisov
2019-05-14 11:45 ` [Xen-devel] " Andrii Anisov
2019-05-14 12:02 ` Jan Beulich
2019-05-14 12:02 ` [Xen-devel] " Jan Beulich
2019-05-14 13:05 ` Andrii Anisov
2019-05-14 13:05 ` [Xen-devel] " Andrii Anisov
2019-05-14 13:49 ` Julien Grall
2019-05-14 13:49 ` [Xen-devel] " Julien Grall
2019-05-15 9:04 ` Andrii Anisov
2019-05-15 9:04 ` [Xen-devel] " Andrii Anisov
2019-05-15 10:31 ` Julien Grall
2019-05-15 10:31 ` [Xen-devel] " Julien Grall
2019-05-14 13:49 ` Jan Beulich
2019-05-14 13:49 ` [Xen-devel] " Jan Beulich
2019-05-15 8:44 ` Andrii Anisov
2019-05-15 8:44 ` [Xen-devel] " Andrii Anisov
2019-05-15 11:59 ` Jan Beulich
2019-05-15 11:59 ` [Xen-devel] " Jan Beulich
2019-05-16 12:09 ` Jan Beulich
2019-05-16 12:09 ` [Xen-devel] " Jan Beulich
2019-05-16 13:30 ` Andrii Anisov
2019-05-16 13:30 ` [Xen-devel] " Andrii Anisov
2019-05-16 13:30 ` Andrii Anisov
2019-05-16 13:30 ` [Xen-devel] " Andrii Anisov
2019-05-16 13:48 ` Julien Grall
2019-05-16 13:48 ` [Xen-devel] " Julien Grall
2019-05-16 14:25 ` Andrii Anisov
2019-05-16 14:25 ` [Xen-devel] " Andrii Anisov
2019-05-16 14:28 ` Julien Grall
2019-05-16 14:28 ` [Xen-devel] " Julien Grall
2019-05-16 14:29 ` Andrii Anisov
2019-05-16 14:29 ` [Xen-devel] " Andrii Anisov
[not found] ` <fa126315-31af-854e-817a-8640b431c82b@arm.com>
[not found] ` <CAC1WxdiMzAq5hRC-mhRQuFDs7z_Hj5w7VAy52ec87SJQOGmp3w@mail.gmail.com>
[not found] ` <a28f95a1-d9da-2caf-f4b4-013100176b02@arm.com>
[not found] ` <090ce8cc-f329-fe54-4894-b7f12e3cd5a6@gmail.com>
2019-05-08 13:39 ` [PATCH v2 0/2] Introduce runstate area registration with phys address Julien Grall
2019-05-08 13:39 ` [Xen-devel] " Julien Grall
2019-05-08 13:54 ` Andrii Anisov
2019-05-08 13:54 ` [Xen-devel] " Andrii Anisov
2019-05-08 14:31 ` Julien Grall
2019-05-08 14:31 ` [Xen-devel] " Julien Grall
2019-05-08 16:01 ` Andrii Anisov
2019-05-08 16:01 ` [Xen-devel] " Andrii Anisov
2019-05-13 10:50 ` Julien Grall
2019-05-13 10:50 ` [Xen-devel] " Julien Grall
2019-05-13 14:34 ` Andrii Anisov
2019-05-13 14:34 ` [Xen-devel] " Andrii Anisov
2019-05-08 13:59 ` Julien Grall
2019-05-13 10:15 ` Andrii Anisov
2019-05-13 11:16 ` Julien Grall
2019-05-13 14:14 ` Andrii Anisov
2019-05-13 14:34 ` Julien Grall
2019-05-13 15:29 ` Andrii Anisov
2019-05-13 15:31 ` Julien Grall
2019-05-13 15:38 ` Andrii Anisov
2019-05-13 15:40 ` Julien Grall
2019-05-13 15:42 ` Andrii Anisov
2019-05-13 15:45 ` Julien Grall
2019-05-13 16:05 ` Andrii Anisov
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=1556007026-31057-1-git-send-email-andrii.anisov@gmail.com \
--to=andrii.anisov@gmail.com \
--cc=JBeulich@suse.com \
--cc=andrii_anisov@epam.com \
--cc=julien.grall@arm.com \
--cc=roger.pau@citrix.com \
--cc=xen-devel@lists.xen.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).