All of lore.kernel.org
 help / color / mirror / Atom feed
From: Alexander Graf <agraf@suse.de>
To: Paul Mackerras <paulus@samba.org>
Cc: kvm-ppc@vger.kernel.org, kvm@vger.kernel.org
Subject: Re: [PATCH v2] KVM: PPC: Book3S HV: Make the guest hash table size configurable
Date: Tue, 15 May 2012 17:17:43 +0000	[thread overview]
Message-ID: <4FB28FB7.2050400@suse.de> (raw)
In-Reply-To: <20120504123253.GA19293@bloggs.ozlabs.ibm.com>

On 05/04/2012 02:32 PM, Paul Mackerras wrote:
> This adds a new ioctl to enable userspace to control the size of the guest
> hashed page table (HPT) and to clear it out when resetting the guest.
> The KVM_PPC_ALLOCATE_HTAB ioctl is a VM ioctl and takes as its parameter
> a pointer to a u32 containing the desired order of the HPT (log base 2
> of the size in bytes), which is updated on successful return to the
> actual order of the HPT which was allocated.
>
> There must be no vcpus running at the time of this ioctl.  To enforce
> this, we now keep a count of the number of vcpus running in
> kvm->arch.vcpus_running.
>
> If the ioctl is called when a HPT has already been allocated, we don't
> reallocate the HPT but just clear it out.  We first clear the
> kvm->arch.rma_setup_done flag, which has two effects: (a) since we hold
> the kvm->lock mutex, it will prevent any vcpus from starting to run until
> we're done, and (b) it means that the first vcpu to run after we're done
> will re-establish the VRMA if necessary.
>
> If userspace doesn't call this ioctl before running the first vcpu, the
> kernel will allocate a default-sized HPT at that point.  We do it then
> rather than when creating the VM, as the code did previously, so that
> userspace has a chance to do the ioctl if it wants.
>
> When allocating the HPT, we can allocate either from the kernel page
> allocator, or from the preallocated pool.  If userspace is asking for
> a different size from the preallocated HPTs, we first try to allocate
> using the kernel page allocator.  Then we try to allocate from the
> preallocated pool, and then if that fails, we try allocating decreasing
> sizes from the kernel page allocator, down to the minimum size allowed
> (256kB).  Note that the kernel page allocator limits allocations to
> 1<<  CONFIG_FORCE_MAX_ZONEORDER pages, which by default corresponds to
> 16MB (on 64-bit powerpc, at least).
>
> Signed-off-by: Paul Mackerras<paulus@samba.org>

Thanks, applied to kvm-ppc-next.


Alex


WARNING: multiple messages have this Message-ID (diff)
From: Alexander Graf <agraf@suse.de>
To: Paul Mackerras <paulus@samba.org>
Cc: kvm-ppc@vger.kernel.org, kvm@vger.kernel.org
Subject: Re: [PATCH v2] KVM: PPC: Book3S HV: Make the guest hash table size configurable
Date: Tue, 15 May 2012 19:17:43 +0200	[thread overview]
Message-ID: <4FB28FB7.2050400@suse.de> (raw)
In-Reply-To: <20120504123253.GA19293@bloggs.ozlabs.ibm.com>

On 05/04/2012 02:32 PM, Paul Mackerras wrote:
> This adds a new ioctl to enable userspace to control the size of the guest
> hashed page table (HPT) and to clear it out when resetting the guest.
> The KVM_PPC_ALLOCATE_HTAB ioctl is a VM ioctl and takes as its parameter
> a pointer to a u32 containing the desired order of the HPT (log base 2
> of the size in bytes), which is updated on successful return to the
> actual order of the HPT which was allocated.
>
> There must be no vcpus running at the time of this ioctl.  To enforce
> this, we now keep a count of the number of vcpus running in
> kvm->arch.vcpus_running.
>
> If the ioctl is called when a HPT has already been allocated, we don't
> reallocate the HPT but just clear it out.  We first clear the
> kvm->arch.rma_setup_done flag, which has two effects: (a) since we hold
> the kvm->lock mutex, it will prevent any vcpus from starting to run until
> we're done, and (b) it means that the first vcpu to run after we're done
> will re-establish the VRMA if necessary.
>
> If userspace doesn't call this ioctl before running the first vcpu, the
> kernel will allocate a default-sized HPT at that point.  We do it then
> rather than when creating the VM, as the code did previously, so that
> userspace has a chance to do the ioctl if it wants.
>
> When allocating the HPT, we can allocate either from the kernel page
> allocator, or from the preallocated pool.  If userspace is asking for
> a different size from the preallocated HPTs, we first try to allocate
> using the kernel page allocator.  Then we try to allocate from the
> preallocated pool, and then if that fails, we try allocating decreasing
> sizes from the kernel page allocator, down to the minimum size allowed
> (256kB).  Note that the kernel page allocator limits allocations to
> 1<<  CONFIG_FORCE_MAX_ZONEORDER pages, which by default corresponds to
> 16MB (on 64-bit powerpc, at least).
>
> Signed-off-by: Paul Mackerras<paulus@samba.org>

Thanks, applied to kvm-ppc-next.


Alex

  reply	other threads:[~2012-05-15 17:17 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-05-04 12:32 [PATCH v2] KVM: PPC: Book3S HV: Make the guest hash table size configurable Paul Mackerras
2012-05-04 12:32 ` Paul Mackerras
2012-05-15 17:17 ` Alexander Graf [this message]
2012-05-15 17:17   ` Alexander Graf

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=4FB28FB7.2050400@suse.de \
    --to=agraf@suse.de \
    --cc=kvm-ppc@vger.kernel.org \
    --cc=kvm@vger.kernel.org \
    --cc=paulus@samba.org \
    /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.