All of lore.kernel.org
 help / color / mirror / Atom feed
From: Paolo Bonzini <pbonzini@redhat.com>
To: Igor Mammedov <imammedo@redhat.com>
Cc: linux-kernel@vger.kernel.org, kvm@vger.kernel.org, x86@kernel.org
Subject: Re: [PATCH] kvm: x86: increase user memory slots to 509
Date: Fri, 14 Nov 2014 15:53:12 +0100	[thread overview]
Message-ID: <54661758.5080707@redhat.com> (raw)
In-Reply-To: <20141114151030.75f588bd@igors-macbook-pro.local>

On 14/11/2014 15:10, Igor Mammedov wrote:
> On Thu, 06 Nov 2014 17:23:58 +0100 Paolo Bonzini <pbonzini@redhat.com> wrote:
>> It would use more memory, and some loops are now becoming more
>> expensive.  In general adding a memory slot to a VM is not cheap, and
>> I question the wisdom of having 256 hotplug memory slots.  But the
>> slowdown mostly would only happen if you actually _use_ those memory
>> slots, so it is not a blocker for this patch.
> It might be useful to have a big amount of slots for big guests
> and although linux works with minimum section 128Mb but Windows memory
> hotplug works just fine even with page-sized slots so when unplug in
> QEMU is implemented it would be possible to drop balooning driver at
> least there.

I think for a big (64G?) guest it doesn't make much sense anyway to
balloon at a granularity that is less than 1G or even more.  So I like
the idea of dropping ballooning in favor of memory hotplug for big guests.

> And providing that memslots could be allocated during runtime when guest
> programs devices or maps roms (i.e. no fail path), I don't see a way
> to fix it in QEMU (i.e. avoid abort when limit is reached).
> Hence an attempt to bump memslots limit to 512, where current 125
> are reserved for initial memory mappings and passthrough devices 
> 256 goes to hotplug memory slots and leaves us 128 free slots for
> future expansion.
> 
> To see what would be affected by large amount of slots I played with
> perf a bit and the biggest hotspot offender with large amount of
> memslots was:
> 
>  gfn_to_memslot() -> ... -> search_memslots()
> 
> I'll try to make it faster for this case so 512 memslots wouldn't
> affect guest performance.
> 
> So please consider applying this patch.

Yes, sorry for the delay---I am definitely going to apply it.

Paolo

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

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-11-06 15:52 [PATCH] kvm: x86: increase user memory slots to 509 Igor Mammedov
2014-11-06 16:23 ` Paolo Bonzini
2014-11-13 16:31   ` [PATCH] kvm: memslots: replace heap sort with insertion sort Igor Mammedov
2014-11-13 16:58     ` Paolo Bonzini
2014-11-13 23:00       ` [PATCH v2] " Igor Mammedov
2014-11-14  9:57         ` Paolo Bonzini
2014-11-14 10:58           ` Igor Mammedov
2014-11-14 14:10   ` [PATCH] kvm: x86: increase user memory slots to 509 Igor Mammedov
2014-11-14 14:53     ` Paolo Bonzini [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=54661758.5080707@redhat.com \
    --to=pbonzini@redhat.com \
    --cc=imammedo@redhat.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=x86@kernel.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.