From: Avi Kivity <avi@qumranet.com>
To: Dave Hansen <dave@linux.vnet.ibm.com>
Cc: kvm-devel <kvm@vger.kernel.org>,
Anthony Liguori <aliguori@us.ibm.com>,
Roland Dreier <rdreier@cisco.com>
Subject: Re: [RFC][PATCH] reduce KVM stack usage
Date: Sat, 19 Jul 2008 10:32:27 +0300 [thread overview]
Message-ID: <4881988B.207@qumranet.com> (raw)
In-Reply-To: <1216308735.9161.3.camel@nimitz>
Dave Hansen wrote:
> KVM uses a lot of kernel stack on x86, especially with gcc 3.x. It
> likes to overflow it and make my poor machine go boom. This patch takes
> the worst stack users and makes them use kmalloc(). It also saves ~30
> bytes in kvm_arch_vm_ioctl() by using a union.
>
> I haven't tested this at all yet. Just posting to get some comments.
>
> Avi, you said that one of these was a hot path. Which one is that? I
> kinda doubt you'll be able to see any impact anyway.
>
>
The pv_mmu_ops thing.
> diff --git a/arch/x86/kvm/mmu.c b/arch/x86/kvm/mmu.c
> index 7e7c396..f4e62f2 100644
> --- a/arch/x86/kvm/mmu.c
> +++ b/arch/x86/kvm/mmu.c
> @@ -2154,18 +2154,24 @@ int kvm_pv_mmu_op(struct kvm_vcpu *vcpu, unsigned long bytes,
> gpa_t addr, unsigned long *ret)
> {
> int r;
> - struct kvm_pv_mmu_op_buffer buffer;
> + struct kvm_pv_mmu_op_buffer *buffer =
> + kmalloc(GFP_KERNEL, sizeof(struct kvm_pv_mmu_op_buffer));
>
> - buffer.ptr = buffer.buf;
> - buffer.len = min_t(unsigned long, bytes, sizeof buffer.buf);
> - buffer.processed = 0;
> + if (!buffer) {
> + *ret = 0;
> + return -ENOMEM;
> + }
> +
> + buffer->ptr = buffer->buf;
> + buffer->len = min_t(unsigned long, bytes, sizeof buffer->buf);
> + buffer->processed = 0;
>
> - r = kvm_read_guest(vcpu->kvm, addr, buffer.buf, buffer.len);
> + r = kvm_read_guest(vcpu->kvm, addr, buffer->buf, buffer->len);
> if (r)
> goto out;
>
> - while (buffer.len) {
> - r = kvm_pv_mmu_op_one(vcpu, &buffer);
> + while (buffer->len) {
> + r = kvm_pv_mmu_op_one(vcpu, buffer);
> if (r < 0)
> goto out;
> if (r == 0)
> @@ -2174,7 +2180,8 @@ int kvm_pv_mmu_op(struct kvm_vcpu *vcpu, unsigned long bytes,
>
> r = 1;
> out:
> - *ret = buffer.processed;
> + *ret = buffer->processed;
> + kfree(buffer);
>
Please change this to store the buffer in vcpu->arch.something, and free
it on vcpu destruction. If this path is called at all, it is called
very often, so it's fine to "waste" those 512 bytes.
Might even allocate it as a field in vcpu->arch, since it's only 512 bytes.
>
> +static int kvm_arch_vm_irqchip_ioctl(struct kvm *kvm, void *argp,
> + unsigned int ioctl)
> +{
> +
> +int x86_kvm_vm_ioctl_set_memory_region(struct kvm *kvm, void *argp)
> +{
>
Please keep the code inlined in kvm_arch_vcpu_ioctl(), as this is a
-stable candidate and I want to keep the patch obvious. A later patch
can break it up.
Please separate the vm ioctl, vcpu ioctl, and pv_mmu_op thing into
separate patches, for bisect goodness.
--
I have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.
prev parent reply other threads:[~2008-07-19 7:32 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-07-17 15:32 [RFC][PATCH] reduce KVM stack usage Dave Hansen
2008-07-17 15:40 ` Roland Dreier
2008-07-17 17:23 ` Dave Hansen
2008-07-17 23:02 ` Roland Dreier
2008-07-19 7:32 ` 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=4881988B.207@qumranet.com \
--to=avi@qumranet.com \
--cc=aliguori@us.ibm.com \
--cc=dave@linux.vnet.ibm.com \
--cc=kvm@vger.kernel.org \
--cc=rdreier@cisco.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox