From mboxrd@z Thu Jan 1 00:00:00 1970 From: Nadav Amit Subject: Re: [RFC PATCH 3/4] kvm: Add guest side support for free memory hints Date: Mon, 4 Feb 2019 17:46:22 -0800 Message-ID: References: <20190204181118.12095.38300.stgit@localhost.localdomain> <20190204181552.12095.46287.stgit@localhost.localdomain> <4E64E8CA-6741-47DF-87DE-88D01B01B15D@gmail.com> <4DFBB378-8E7A-4905-A94D-D56B5FF6D42B@gmail.com> Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: Alexander Duyck , Linux-MM , LKML , kvm list , Radim Krcmar , X86 ML , Ingo Molnar , Borislav Petkov , Peter Anvin , Paolo Bonzini , Thomas Gleixner , Andrew Morton To: Alexander Duyck Return-path: In-Reply-To: Sender: linux-kernel-owner@vger.kernel.org List-Id: kvm.vger.kernel.org > On Feb 4, 2019, at 4:16 PM, Alexander Duyck = wrote: >=20 > On Mon, Feb 4, 2019 at 4:03 PM Nadav Amit = wrote: >>> On Feb 4, 2019, at 3:37 PM, Alexander Duyck = wrote: >>>=20 >>> On Mon, 2019-02-04 at 15:00 -0800, Nadav Amit wrote: >>>>> On Feb 4, 2019, at 10:15 AM, Alexander Duyck = wrote: >>>>>=20 >>>>> From: Alexander Duyck >>>>>=20 >>>>> Add guest support for providing free memory hints to the KVM = hypervisor for >>>>> freed pages huge TLB size or larger. I am restricting the size to >>>>> huge TLB order and larger because the hypercalls are too expensive = to be >>>>> performing one per 4K page. Using the huge TLB order became the = obvious >>>>> choice for the order to use as it allows us to avoid fragmentation = of higher >>>>> order memory on the host. >>>>>=20 >>>>> I have limited the functionality so that it doesn't work when page >>>>> poisoning is enabled. I did this because a write to the page after = doing an >>>>> MADV_DONTNEED would effectively negate the hint, so it would be = wasting >>>>> cycles to do so. >>>>>=20 >>>>> Signed-off-by: Alexander Duyck >>>>> --- >>>>> arch/x86/include/asm/page.h | 13 +++++++++++++ >>>>> arch/x86/kernel/kvm.c | 23 +++++++++++++++++++++++ >>>>> 2 files changed, 36 insertions(+) >>>>>=20 >>>>> diff --git a/arch/x86/include/asm/page.h = b/arch/x86/include/asm/page.h >>>>> index 7555b48803a8..4487ad7a3385 100644 >>>>> --- a/arch/x86/include/asm/page.h >>>>> +++ b/arch/x86/include/asm/page.h >>>>> @@ -18,6 +18,19 @@ >>>>>=20 >>>>> struct page; >>>>>=20 >>>>> +#ifdef CONFIG_KVM_GUEST >>>>> +#include >>>>> +extern struct static_key_false pv_free_page_hint_enabled; >>>>> + >>>>> +#define HAVE_ARCH_FREE_PAGE >>>>> +void __arch_free_page(struct page *page, unsigned int order); >>>>> +static inline void arch_free_page(struct page *page, unsigned int = order) >>>>> +{ >>>>> + if (static_branch_unlikely(&pv_free_page_hint_enabled)) >>>>> + __arch_free_page(page, order); >>>>> +} >>>>> +#endif >>>>=20 >>>> This patch and the following one assume that only KVM should be = able to hook >>>> to these events. I do not think it is appropriate for = __arch_free_page() to >>>> effectively mean =E2=80=9Ckvm_guest_free_page()=E2=80=9D. >>>>=20 >>>> Is it possible to use the paravirt infrastructure for this feature, >>>> similarly to other PV features? It is not the best infrastructure, = but at least >>>> it is hypervisor-neutral. >>>=20 >>> I could probably tie this into the paravirt infrastructure, but if I >>> did so I would probably want to pull the checks for the page order = out >>> of the KVM specific bits and make it something we handle in the = inline. >>> Doing that I would probably make it a paravirtual hint that only >>> operates at the PMD level. That way we wouldn't incur the cost of = the >>> paravirt infrastructure at the per 4K page level. >>=20 >> If I understand you correctly, you =E2=80=9Ccomplain=E2=80=9D that = this would affect >> performance. >=20 > It wasn't so much a "complaint" as an "observation". What I was > getting at is that if I am going to make it a PV operation I might set > a hard limit on it so that it will specifically only apply to huge > pages and larger. By doing that I can justify performing the screening > based on page order in the inline path and avoid any PV infrastructure > overhead unless I have to incur it. I understood. I guess my use of =E2=80=9Cdouble quotes=E2=80=9D was lost = in translation. ;-) One more point regarding [2/4] - you may want to consider using = madvise_free instead of madvise_dontneed to avoid unnecessary EPT violations.