From: Michael Ellerman <mpe@ellerman.id.au>
To: Nathan Lynch via B4 Relay
<devnull+nathanl.linux.ibm.com@kernel.org>,
Nicholas Piggin <npiggin@gmail.com>,
"Aneesh Kumar K.V" <aneesh.kumar@linux.ibm.com>,
"Naveen N. Rao" <naveen.n.rao@linux.ibm.com>,
Brian King <brking@linux.ibm.com>
Cc: Nathan Lynch <nathanl@linux.ibm.com>, linuxppc-dev@lists.ozlabs.org
Subject: Re: [PATCH RFC] powerpc/pseries: exploit H_PAGE_SET_UNUSED for partition migration
Date: Tue, 20 Feb 2024 23:16:51 +1100 [thread overview]
Message-ID: <87edd7baa4.fsf@mail.lhotse> (raw)
In-Reply-To: <20240111-h_page_set_unused-for-lpm-v1-1-cd56184ad608@linux.ibm.com>
Nathan Lynch via B4 Relay <devnull+nathanl.linux.ibm.com@kernel.org>
writes:
> From: Nathan Lynch <nathanl@linux.ibm.com>
>
> Although the H_PAGE_INIT hcall's H_PAGE_SET_UNUSED historically has
> been tied to the cooperative memory overcommit (CMO) platform feature,
> the flag also is treated by the PowerVM hypervisor as a hint that the
> page contents need not be copied to the destination during a live
> partition migration.
>
> Use the "ibm,migratable-partition" root node property to determine
> whether this partition/guest can be migrated. Mark freed pages unused
> if so (or if CMO is in use, as before).
>
> Signed-off-by: Nathan Lynch <nathanl@linux.ibm.com>
> ---
> Several things yet to improve here:
>
> * powerpc's arch_free_page()/HAVE_ARCH_FREE_PAGE should be decoupled
> from CONFIG_PPC_SMLPAR.
>
> * powerpc's arch_free_page() could be made to use a static key if
> justified.
>
> * I have not yet measured the overhead this introduces, nor have I
> measured the benefit to a live migration.
>
> To date, I have smoke tested it by doing a live migration and
> performing a build on a kernel with the change, to ensure it doesn't
> introduce obvious memory corruption or anything. It hasn't blown up
> yet :-)
>
> This will be a possibly significant behavior change in that we will be
> flagging pages unused where we typically did not before. Until now,
> having CMO enabled was the only way to do this, and I don't think that
> feature is used all that much?
Yeah AFAIK it has to be explicitly configured and enabled via the HMC,
so doesn't get much testing or usage.
> Posting this as RFC to see if there are any major concerns.
My worry is that this will add overhead for everyone in normal usage, an
hcall per freed set of pages, whereas the benefit is only seen when a
migration happens.
But that does depend on how often arch_free_page() gets called in normal
usage, which I don't know offhand.
cheers
next prev parent reply other threads:[~2024-02-20 12:17 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-01-11 23:47 [PATCH RFC] powerpc/pseries: exploit H_PAGE_SET_UNUSED for partition migration Nathan Lynch via B4 Relay
2024-02-19 22:25 ` Nathan Lynch
2024-02-20 12:16 ` Michael Ellerman [this message]
2024-02-20 16:20 ` Nathan Lynch
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=87edd7baa4.fsf@mail.lhotse \
--to=mpe@ellerman.id.au \
--cc=aneesh.kumar@linux.ibm.com \
--cc=brking@linux.ibm.com \
--cc=devnull+nathanl.linux.ibm.com@kernel.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=nathanl@linux.ibm.com \
--cc=naveen.n.rao@linux.ibm.com \
--cc=npiggin@gmail.com \
/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).