All of lore.kernel.org
 help / color / mirror / Atom feed
From: Matthew Wilcox <willy@infradead.org>
To: Marc Orr <marcorr@google.com>
Cc: Jim Mattson <jmattson@google.com>,
	Wanpeng Li <kernellwp@gmail.com>,
	kvm@vger.kernel.org, David Rientjes <rientjes@google.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	linux-mm@kvack.org, akpm@linux-foundation.org,
	pbonzini@redhat.com, rkrcmar@redhat.com,
	sean.j.christopherson@intel.com
Subject: Re: [kvm PATCH v4 0/2] use vmalloc to allocate vmx vcpus
Date: Wed, 31 Oct 2018 06:27:51 -0700	[thread overview]
Message-ID: <20181031132751.GL10491@bombadil.infradead.org> (raw)
In-Reply-To: <CAA03e5GT4gR4iN-na0PR_oTrXKVuD8BRcHcR8Y58==eRae3iXA@mail.gmail.com>

On Wed, Oct 31, 2018 at 01:17:40PM +0000, Marc Orr wrote:
> All that being said, I don't really understand why we wouldn't convert
> this memory allocation from a kmalloc() into a vmalloc(). From my
> point of view, we are still close to bloating vcpu_vmx into an order 3
> allocation, and it's common for vendors to append to both vcpu_vmx
> directly, or more likely to its embedded structs. Though, arguably,
> vendors should not be doing that.
> 
> Most importantly, it just isn't obvious to me why kmalloc() is
> preferred over vmalloc(). From my point of view, vmalloc() does the
> exact same thing as kmalloc(), except that it works when contiguous
> memory is sparse, which seems better to me.

It's ever-so-slightly faster to access kmalloc memory than vmalloc memory;
kmalloc memory comes from the main kernel mapping, generally mapped with
1GB pages while vmalloc memory is necessarily accessed using 4kB pages,
taking an extra two steps in the page table hierarchy.  There's more
software overhead involved too; in addition to allocating the physical
pages (which both kmalloc and vmalloc have to do), vmalloc has to allocate
a vmap_area and a vm_struct to describe the virtual mapping.

The virtual address space can also get fragmented, just like the physical
address space does, potentially leading to the amusing scenario where
you can allocate physically contiguous memory, but not find a contiguous
chunk of vmalloc space to put it in.

For larger allocations, we tend to prefer kvmalloc() which gives us
the best of both worlds, allocating from kmalloc first and vmalloc as a
fallback, but you've got some fun gyrations to go through to do physical
mapping, so that's not entirely appropriate for your case.

  reply	other threads:[~2018-10-31 13:27 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-10-26  7:58 [kvm PATCH v4 0/2] use vmalloc to allocate vmx vcpus Marc Orr
2018-10-26  7:58 ` [kvm PATCH v4 1/2] kvm: vmx: refactor vmx_msrs struct for vmalloc Marc Orr
2018-10-26 11:02   ` Sean Christopherson
2018-10-26  7:59 ` [kvm PATCH v4 2/2] kvm: vmx: use vmalloc() to allocate vcpus Marc Orr
2018-10-26 12:29 ` [kvm PATCH v4 0/2] use vmalloc to allocate vmx vcpus Matthew Wilcox
2018-10-26 14:45   ` Matthew Wilcox
2018-10-26 14:49     ` Dave Hansen
2018-10-31 13:06       ` Marc Orr
2018-10-29  1:58 ` Wanpeng Li
2018-10-29 16:25   ` Jim Mattson
2018-10-29 16:48     ` Matthew Wilcox
2018-10-29 18:12       ` Jim Mattson
2018-10-29 19:16         ` Marc Orr
2018-10-29 19:22           ` Marc Orr
2018-10-31 13:17       ` Marc Orr
2018-10-31 13:27         ` Matthew Wilcox [this message]
2018-10-31 13:48           ` Marc Orr
2018-10-31 14:21             ` Matthew Wilcox
2018-10-31 21:19               ` Marc Orr

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=20181031132751.GL10491@bombadil.infradead.org \
    --to=willy@infradead.org \
    --cc=akpm@linux-foundation.org \
    --cc=jmattson@google.com \
    --cc=kernellwp@gmail.com \
    --cc=konrad.wilk@oracle.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=marcorr@google.com \
    --cc=pbonzini@redhat.com \
    --cc=rientjes@google.com \
    --cc=rkrcmar@redhat.com \
    --cc=sean.j.christopherson@intel.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.