All of lore.kernel.org
 help / color / mirror / Atom feed
From: Juergen Gross <jgross@suse.com>
To: David Vrabel <david.vrabel@citrix.com>,
	linux-kernel@vger.kernel.org, xen-devel@lists.xensource.com,
	konrad.wilk@oracle.com, boris.ostrovsky@oracle.com,
	x86@kernel.org, tglx@linutronix.de, mingo@redhat.com,
	hpa@zytor.com
Subject: Re: [Xen-devel] [PATCH V2 5/5] Xen: switch to linear virtual mapped sparse p2m list
Date: Fri, 07 Nov 2014 15:11:18 +0100	[thread overview]
Message-ID: <545CD306.90001@suse.com> (raw)
In-Reply-To: <545CCF15.4070402@citrix.com>

On 11/07/2014 02:54 PM, David Vrabel wrote:
> On 06/11/14 05:47, Juergen Gross wrote:
>> At start of the day the Xen hypervisor presents a contiguous mfn list
>> to a pv-domain. In order to support sparse memory this mfn list is
>> accessed via a three level p2m tree built early in the boot process.
>> Whenever the system needs the mfn associated with a pfn this tree is
>> used to find the mfn.
>>
>> Instead of using a software walked tree for accessing a specific mfn
>> list entry this patch is creating a virtual address area for the
>> entire possible mfn list including memory holes. The holes are
>> covered by mapping a pre-defined  page consisting only of "invalid
>> mfn" entries. Access to a mfn entry is possible by just using the
>> virtual base address of the mfn list and the pfn as index into that
>> list. This speeds up the (hot) path of determining the mfn of a
>> pfn.
>>
>> Kernel build on a Dell Latitude E6440 (2 cores, HT) in 64 bit Dom0
>> showed following improvements:
>>
>> Elapsed time: 32:50 ->  32:35
>> System:       18:07 ->  17:47
>> User:        104:00 -> 103:30
>
> After implementing my suggestions below, please provided updated figure.
>   They should be better.

In dom0? I don't think so.

>
>> Tested on 64 bit dom0 and 32 bit domU.
> [...]
>> --- a/arch/x86/include/asm/xen/page.h
>> +++ b/arch/x86/include/asm/xen/page.h
>> @@ -59,6 +59,23 @@ extern int clear_foreign_p2m_mapping(struct gnttab_unmap_grant_ref *unmap_ops,
>>   				     struct page **pages, unsigned int count);
>>   extern unsigned long m2p_find_override_pfn(unsigned long mfn, unsigned long pfn);
>>
>> +static inline unsigned long __pfn_to_mfn(unsigned long pfn)
>
> These variations of pfn_to_mfn() (__pfn_to_mfn() and
> get_phys_to_machine() and any others), need comments explaining their
> differences.
>
> Can you add __pfn_to_mfn() and the docs in a separate patch?

Okay.

>
>> +	pr_notice("p2m virtual area at %p, size is %lx\n", vm.addr, vm.size);
>
> pr_info().
>
>> @@ -526,23 +411,83 @@ unsigned long get_phys_to_machine(unsigned long pfn)
>>   		return IDENTITY_FRAME(pfn);
>>   	}
>>
>> -	topidx = p2m_top_index(pfn);
>> -	mididx = p2m_mid_index(pfn);
>> -	idx = p2m_index(pfn);
>> +	ptep = lookup_address((unsigned long)(xen_p2m_addr + pfn), &level);
>> +	BUG_ON(!ptep || level != PG_LEVEL_4K);
>>
>>   	/*
>>   	 * The INVALID_P2M_ENTRY is filled in both p2m_*identity
>>   	 * and in p2m_*missing, so returning the INVALID_P2M_ENTRY
>>   	 * would be wrong.
>>   	 */
>> -	if (p2m_top[topidx][mididx] == p2m_identity)
>> +	if (pte_pfn(*ptep) == PFN_DOWN(__pa(p2m_identity)))
>>   		return IDENTITY_FRAME(pfn);
>>
>> -	return p2m_top[topidx][mididx][idx];
>> +	return xen_p2m_addr[pfn];
>
> You should test xen_p2m_addr[pfn] == INVALID_P2M_ENTRY before checking
> if it's an identity entry.  This should skip the more expensive
> lookup_address() in the common case.

I do. The check is in __pfn_to_mfn(). get_phys_to_machine() is called in
this case only.

>
>>   bool __set_phys_to_machine(unsigned long pfn, unsigned long mfn)
>
> I think you should map p2m_missing and p2m_identity as read-only and do
> the new page allocation on a write fault.
>
> set_phys_to_machine() is used every grant map and unmap and in the
> common case (already allocated array page) it must be a fast and simple:
>
>      xen_p2m_addr[pfn] = mfn;

Nice idea. I'll try it.


Juergen

  reply	other threads:[~2014-11-07 14:11 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-11-06  5:47 [PATCH V2 0/5] xen: Switch to virtual mapped linear p2m list Juergen Gross
2014-11-06  5:47 ` [PATCH V2 1/5] Xen: Delay remapping memory of pv-domain Juergen Gross
2014-11-07 14:57   ` [Xen-devel] " David Vrabel
2014-11-07 14:57     ` David Vrabel
2014-11-06  5:47 ` [PATCH V2 2/5] xen: Delay m2p_override initialization Juergen Gross
2014-11-07 13:04   ` [Xen-devel] " David Vrabel
2014-11-07 13:04     ` David Vrabel
2014-11-07 13:19     ` Juergen Gross
2014-11-07 14:08       ` David Vrabel
2014-11-07 14:08         ` David Vrabel
2014-11-06  5:47 ` [PATCH V2 3/5] xen: Delay invalidating extra memory Juergen Gross
2014-11-07 13:57   ` David Vrabel
2014-11-07 13:57     ` David Vrabel
2014-11-06  5:47 ` [PATCH V2 4/5] x86: Introduce function to get pmd entry pointer Juergen Gross
2014-11-06  5:47 ` [PATCH V2 5/5] Xen: switch to linear virtual mapped sparse p2m list Juergen Gross
2014-11-07 13:54   ` [Xen-devel] " David Vrabel
2014-11-07 13:54     ` David Vrabel
2014-11-07 14:11     ` Juergen Gross [this message]
2014-11-07 14:40       ` David Vrabel
2014-11-07 14:40         ` David Vrabel
2014-11-07 14:43         ` Juergen Gross

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=545CD306.90001@suse.com \
    --to=jgross@suse.com \
    --cc=boris.ostrovsky@oracle.com \
    --cc=david.vrabel@citrix.com \
    --cc=hpa@zytor.com \
    --cc=konrad.wilk@oracle.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=tglx@linutronix.de \
    --cc=x86@kernel.org \
    --cc=xen-devel@lists.xensource.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 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.