All of lore.kernel.org
 help / color / mirror / Atom feed
From: Avi Kivity <avi@redhat.com>
To: Max Laier <max@laiers.net>
Cc: kvm@vger.kernel.org
Subject: Re: RFC: shadow page table reclaim
Date: Wed, 02 Sep 2009 14:31:20 +0300	[thread overview]
Message-ID: <4A9E5788.2000306@redhat.com> (raw)
In-Reply-To: <200909020424.03358.max@laiers.net>

On 09/02/2009 05:24 AM, Max Laier wrote:
> Okay ... I have/something/, but I'm certainly not there yet as I have to
> admit that I don't understand your idea completely.  In addition it seems that
> EPT doesn't have an accessed bit :-\  Any idea for this?
>    

Use the rwx bits as an approximation.  If the pages are needed they'll 
be faulted back in, which is a lot cheaper than reconstructing them.

But why do you see reclaim with ept?  The pages ought to be constructed 
once and then left alone, unless there is severe memory pressure.

> Regardless, testing the attached with EPT, it turns out that not zapping
> shadow pages with root_count != 0 already makes much difference.  After all we
> don't really zap these pages anyways, but just mark them invalid after zapping
> the children.  So this could be a first improvement.
>
> In any case, I clearly don't have the right idea here, yet.  Plus I don't
> really have time to look into this further right now.  And my hack is "good
> enough"[tm] for my testing ... so if anyone more knowledgeable would like to
> continue - much appreciated.  Maybe some of this can at least serve as food
> for thoughts.  Sorry.
>    

Sure.

> diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h
> index a3f637f..089ad0e 100644
> --- a/arch/x86/include/asm/kvm_host.h
> +++ b/arch/x86/include/asm/kvm_host.h
> @@ -394,6 +394,7 @@ struct kvm_arch{
>   	 * Hash table of struct kvm_mmu_page.
>   	 */
>   	struct list_head active_mmu_pages;
> +	struct kvm_mmu_page *scan_hand;
>   	struct list_head assigned_dev_head;
>   	struct iommu_domain *iommu_domain;
>   	int iommu_flags;
>    

Why is a scan hand needed?  I though you could just clear the accessed 
bits and requeue the page.

If you drop a page, all the accessed bits in the ptes are lost with it, 
so you need to transfer them to the pointed-to pages before you dropped 
it.  Other than that, this seems pretty complete.

-- 
error compiling committee.c: too many arguments to function


      reply	other threads:[~2009-09-02 11:31 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-08-28  2:31 RFC: shadow page table reclaim Max Laier
2009-08-31  9:55 ` Avi Kivity
2009-08-31 12:09   ` Max Laier
2009-08-31 12:40     ` Avi Kivity
2009-09-02  2:24       ` Max Laier
2009-09-02 11:31         ` Avi Kivity [this message]

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=4A9E5788.2000306@redhat.com \
    --to=avi@redhat.com \
    --cc=kvm@vger.kernel.org \
    --cc=max@laiers.net \
    /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.