From: "Edwin Török" <edvin.torok@citrix.com>
To: <xen-devel@lists.xenproject.org>
Cc: pau.safont@citrix.com, "Edwin Török" <edvin.torok@citrix.com>,
"Christian Lindig" <christian.lindig@citrix.com>,
"David Scott" <dave@recoil.org>, "Wei Liu" <wl@xen.org>,
"Anthony PERARD" <anthony.perard@citrix.com>
Subject: [PATCH for-4.17 v1 0/2] xenctrl.ml: improve scalability of domain_getinfolist
Date: Tue, 1 Nov 2022 17:59:15 +0000 [thread overview]
Message-ID: <cover.1667324874.git.edvin.torok@citrix.com> (raw)
Pau has performed some performance tests by booting 1000 mirage
unikernels test VMs and shutting them down.
We've noticed on the flamegraphs that a lot of time is spent in Xenctrl
`domain_getinfolist`, 17.7% of overall time
(This needs to be multiplied by 16 because Dom0 100% usage = 16 vCPUs)
In particular time is spent in camlXenctrl___getlist_339
as can be seen from this flamegraph, and it also creates a very deep
call stack:
https://cdn.jsdelivr.net/gh/edwintorok/xen@xenctrl-coverletter/docs/tmp/perf-merge-boot.svg?x=948.9&y=2213
After some algorithmic improvements to the code now the function barely
shows up at all on a flamegraph, taking only 0.02%.
The function is called camlXenctrl___getlist_343, but that is just due
to the changed arguments, still the same function:
https://cdn.jsdelivr.net/gh/edwintorok/xen@xenctrl-coverletter/docs/tmp/perf-xen-boot-1150.svg?x=1188.0&y=1941&s=infolist
It was calling the Xen hypercall ~500*1000 times for 1000 VMs, and
instead it is now calling it "only" 1000 times.
I would suggest to try to take this in 4.17 given the massive
improvement in scalability (number of VMs on a Xen host).
There are further improvements possible here, but they'll be in xenopsd
(part of XAPI) to avoid calling domain_getinfolist and just use
domain_getinfo: the only reason it needs use infolist is that it does
the lookup by VM UUID and not by domid, but it could have a small cache
of UUID->domid mappings and then call just domain_getinfo (or get the
mapping from xenstore if not in the cache), but it looks like that
improvement is not even needed if this function barely registers on a
flamegraph now.
P.S.: the mirage test VM is a very old PV version, at some point we'll
repeat the test with a Solo5 based PVH one.
Edwin Török (2):
xenctrl.ml: make domain_getinfolist tail recursive
xenctrl: use larger chunksize in domain_getinfolist
tools/ocaml/libs/xc/xenctrl.ml | 25 ++++++++++++++++++-------
1 file changed, 18 insertions(+), 7 deletions(-)
--
2.34.1
next reply other threads:[~2022-11-01 18:00 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-11-01 17:59 Edwin Török [this message]
2022-11-01 17:59 ` [PATCH for-4.17 v1 1/2] xenctrl.ml: make domain_getinfolist tail recursive Edwin Török
2022-11-01 17:59 ` [PATCH for-4.17 v1 2/2] xenctrl: use larger chunksize in domain_getinfolist Edwin Török
2022-11-02 9:11 ` [PATCH for-4.17 v1 0/2] xenctrl.ml: improve scalability of domain_getinfolist Christian Lindig
2022-11-02 9:31 ` Edwin Torok
2022-11-02 9:37 ` Edwin Torok
2022-11-02 17:26 ` Further issues " Andrew Cooper
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=cover.1667324874.git.edvin.torok@citrix.com \
--to=edvin.torok@citrix.com \
--cc=anthony.perard@citrix.com \
--cc=christian.lindig@citrix.com \
--cc=dave@recoil.org \
--cc=pau.safont@citrix.com \
--cc=wl@xen.org \
--cc=xen-devel@lists.xenproject.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.