From: Andrew Cooper <andrew.cooper3@citrix.com>
To: Olaf Hering <olaf@aepfle.de>, <xen-devel@lists.xenproject.org>
Cc: George Dunlap <george.dunlap@citrix.com>,
Ian Jackson <iwj@xenproject.org>, Jan Beulich <jbeulich@suse.com>,
Julien Grall <julien@xen.org>,
Stefano Stabellini <sstabellini@kernel.org>, Wei Liu <wl@xen.org>,
Anthony PERARD <anthony.perard@citrix.com>
Subject: Re: [PATCH v4] tools: create libxensaverestore
Date: Thu, 22 Apr 2021 12:49:14 +0100 [thread overview]
Message-ID: <39eb928b-161d-4870-93d2-8c15929aa32f@citrix.com> (raw)
In-Reply-To: <20210415131138.8709-1-olaf@aepfle.de>
On 15/04/2021 14:11, Olaf Hering wrote:
> Move all save/restore related code from libxenguest.so into a separate
> library libxensaverestore.so. The only consumer is libxl-save-helper.
"in tree consumer".
It's not the only consumer, but XenServer's equivalent of
libxl-save-helper is in a position to consume this library.
That said, if you've dropped the plans for the static version, I don't
see what the point is. You're literally saving 15 pages of memory (so
nothing in the grand scheme of a userspace process), at the cost of
added effort for the dynamic loader.
In this form, there's a reasonable chance that it adds to the perf
problems you're trying to address.
> There is no need to have the moved code mapped all the time in binaries
> where libxenguest.so is used.
>
> According to size(1) the change is:
> text data bss dec hex filename
> 187183 4304 48 191535 2ec2f guest/libxenguest.so.4.15.0
>
> 124106 3376 48 127530 1f22a guest/libxenguest.so.4.15.0
> 67841 1872 8 69721 11059 saverestore/libxensaverestore.so.4.15.0
>
> While touching the files anyway, take the opportunity to drop the
> reduntant xg_sr_ filename prefix.
>
> Signed-off-by: Olaf Hering <olaf@aepfle.de>
> ---
> diff --git a/tools/libs/saverestore/Makefile b/tools/libs/saverestore/Makefile
> new file mode 100644
> index 0000000000..48728b3be2
> --- /dev/null
> +++ b/tools/libs/saverestore/Makefile
> @@ -0,0 +1,38 @@
> +XEN_ROOT = $(CURDIR)/../../..
> +include $(XEN_ROOT)/tools/Rules.mk
> +
> +ifeq ($(CONFIG_MIGRATE),y)
> +SRCS-y += common.c
> +SRCS-$(CONFIG_X86) += common_x86.c
> +SRCS-$(CONFIG_X86) += common_x86_pv.c
> +SRCS-$(CONFIG_X86) += restore_x86_pv.c
> +SRCS-$(CONFIG_X86) += restore_x86_hvm.c
> +SRCS-$(CONFIG_X86) += save_x86_pv.c
> +SRCS-$(CONFIG_X86) += save_x86_hvm.c
> +SRCS-y += restore.c
> +SRCS-y += save.c
> +else
> +SRCS-y += nomigrate.c
> +endif
Depending on the answers to the general question above...
I don't think pulling nomigrate into this new library is sensible. A
dedicate migration library, stubbed to errors based on some exterior
setting, is very rude.
Given the proposed new structure, the way this ought to be expressed is
libxl-save-restore-helper being conditional on CONFIG_MIGRATE in the
first place.
Also, xensaverestore is a mouthful. If we are changing things, how
about xenmigrate instead?
~Andrew
next prev parent reply other threads:[~2021-04-22 11:49 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-04-15 13:11 [PATCH v4] tools: create libxensaverestore Olaf Hering
2021-04-21 10:26 ` Wei Liu
2021-04-22 11:49 ` Andrew Cooper [this message]
2021-04-22 12:27 ` Olaf Hering
2021-04-22 12:46 ` Olaf Hering
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=39eb928b-161d-4870-93d2-8c15929aa32f@citrix.com \
--to=andrew.cooper3@citrix.com \
--cc=anthony.perard@citrix.com \
--cc=george.dunlap@citrix.com \
--cc=iwj@xenproject.org \
--cc=jbeulich@suse.com \
--cc=julien@xen.org \
--cc=olaf@aepfle.de \
--cc=sstabellini@kernel.org \
--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 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).