Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752241AbdFNRL7 (ORCPT ); Wed, 14 Jun 2017 13:11:59 -0400 Received: from mx2.suse.de ([195.135.220.15]:58409 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1751958AbdFNRL6 (ORCPT ); Wed, 14 Jun 2017 13:11:58 -0400 Subject: Re: [PATCH] xen: allocate page for shared info page from low memory To: Boris Ostrovsky , linux-kernel@vger.kernel.org, xen-devel@lists.xenproject.org References: <20170612115356.8312-1-jgross@suse.com> From: Juergen Gross Message-ID: Date: Wed, 14 Jun 2017 19:11:55 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Language: de-DE Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2680 Lines: 76 On 14/06/17 18:58, Boris Ostrovsky wrote: > On 06/12/2017 07:53 AM, Juergen Gross wrote: >> In a HVM guest the kernel allocates the page for mapping the shared >> info structure via extend_brk() today. This will lead to a drop of >> performance as the underlying EPT entry will have to be split up into >> 4kB entries as the single shared info page is located in hypervisor >> memory. >> >> The issue has been detected by using the libmicro munmap test: >> unmapping 8kB of memory was faster by nearly a factor of two when no >> pv interfaces were active in the HVM guest. >> >> So instead of taking a page from memory which might be mapped via >> large EPT entries use a page which is already mapped via a 4kB EPT >> entry: we can take a page from the first 1MB of memory as the video >> memory at 640kB disallows using larger EPT entries. >> >> Signed-off-by: Juergen Gross >> --- >> arch/x86/xen/enlighten_hvm.c | 31 ++++++++++++++++++++++++------- >> arch/x86/xen/enlighten_pv.c | 2 -- >> 2 files changed, 24 insertions(+), 9 deletions(-) >> >> diff --git a/arch/x86/xen/enlighten_hvm.c b/arch/x86/xen/enlighten_hvm.c >> index a6d014f47e52..c19477b6e43a 100644 >> --- a/arch/x86/xen/enlighten_hvm.c >> +++ b/arch/x86/xen/enlighten_hvm.c >> @@ -1,5 +1,6 @@ >> #include >> #include >> +#include >> >> #include >> #include >> @@ -10,9 +11,11 @@ >> #include >> #include >> #include >> +#include >> >> #include >> #include >> +#include >> >> #include "xen-ops.h" >> #include "mmu.h" >> @@ -22,20 +25,34 @@ void __ref xen_hvm_init_shared_info(void) >> { >> int cpu; >> struct xen_add_to_physmap xatp; >> - static struct shared_info *shared_info_page; >> + u64 pa; >> + >> + if (HYPERVISOR_shared_info == &xen_dummy_shared_info) { >> + /* >> + * Search for a free page starting at 4kB physical address. >> + * Low memory is preferred to avoid an EPT large page split up >> + * by the mapping. >> + * Starting below X86_RESERVE_LOW (usually 64kB) is fine as >> + * the BIOS used for HVM guests is well behaved and won't >> + * clobber memory other than the first 4kB. >> + */ >> + for (pa = PAGE_SIZE; >> + !e820__mapped_all(pa, pa + PAGE_SIZE, E820_TYPE_RAM) || >> + memblock_is_reserved(pa); >> + pa += PAGE_SIZE) >> + ; > > Is it possible to never find a page here? Only if there is no memory available at all. :-) TBH: I expect this to _always_ succeed at the first loop iteration. Juergen