All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrea Arcangeli <aarcange@redhat.com>
To: Stefan Hajnoczi <stefanha@gmail.com>
Cc: Lai Jiangshan <jiangshanlai@gmail.com>,
	Samuel Ortiz <sameo@linux.intel.com>, Xu Wang <gnawux@gmail.com>,
	qemu-devel@nongnu.org,
	"James O . D . Hunt" <james.o.hunt@intel.com>,
	Peng Tao <bergwolf@gmail.com>,
	"Dr. David Alan Gilbert" <dgilbert@redhat.com>,
	Markus Armbruster <armbru@redhat.com>,
	Juan Quintela <quintela@redhat.com>,
	Sebastien Boeuf <sebastien.boeuf@intel.com>,
	Xiao Guangrong <xiaoguangrong@tencent.com>,
	Xiao Guangrong <xiaoguangrong.eric@gmail.com>,
	Paolo Bonzini <pbonzini@redhat.com>,
	Marcelo Tosatti <mtosatti@redhat.com>
Subject: Re: [Qemu-devel] [PATCH] migration: add capability to bypass the shared memory
Date: Mon, 2 Jul 2018 18:01:32 -0400	[thread overview]
Message-ID: <20180702220132.GA8790@redhat.com> (raw)
In-Reply-To: <20180702131054.GE2155@stefanha-x1.localdomain>

Hello everyone,

On Mon, Jul 02, 2018 at 02:10:54PM +0100, Stefan Hajnoczi wrote:
> Marcelo, Andrea, Paolo: There was a more complex local migration
> approach in 2013 with fd passing and vmsplice.  They specifically
> avoided the approach proposed in this patch, but I don't remember why.
> 
> The closest to an explanation I've found is this message from Marcelo:
> 
>   Another possibility is to use memory that is not anonymous for guest
>   RAM, such as hugetlbfs or tmpfs.
> 
>   IIRC ksm and thp have limitations wrt tmpfs.
> 
> https://www.spinics.net/lists/linux-mm/msg67437.html
> 
> Have the limitations been been solved since then?

tmpfs supports THP upstream nawadays, but it's not the default.

About KSM on non-anonymous memory it's not happening any time soon,
I'm not aware of anybody working on it and it's major change not
easily staying contained within KSM so it would take time. There have
been multiple requests for this feature (but usually for bare metal
containers).

The higher priority items for KSM are in terms of xxhash and/or
accellerated crc32 and perhaps multithreading the scanner to use more
cores. Those are fully self contained issues and they won't make the
rest of the kernel more complex.

Such kind of setup simply brings some of the limitations that
vhost-user/DPDK also has.

Thanks,
Andrea

      parent reply	other threads:[~2018-07-02 22:01 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-03-31  8:45 [Qemu-devel] [PATCH] migration: add capability to bypass the shared memory Lai Jiangshan
2018-03-31 10:17 ` Lai Jiangshan
2018-03-31 12:35 ` Eric Blake
2018-04-01  8:48 ` [Qemu-devel] [PATCH V3] " Lai Jiangshan
2018-04-01  8:53   ` no-reply
2018-04-01  8:56   ` no-reply
2018-04-04 11:47   ` [Qemu-devel] [PATCH V4] " Lai Jiangshan
2018-04-04 12:15     ` Xiao Guangrong
2018-04-09 17:30     ` Dr. David Alan Gilbert
2018-04-12  2:34       ` Lai Jiangshan
2018-04-16 15:00         ` [Qemu-devel] [PATCH V5] " Lai Jiangshan
2018-04-19 16:38           ` Dr. David Alan Gilbert
2018-04-25 10:12             ` Lai Jiangshan
2018-04-26 19:05               ` Dr. David Alan Gilbert
2018-04-27  7:47                 ` Cédric Le Goater
2018-06-28  0:42           ` Liang Li
2018-04-16 22:54       ` [Qemu-devel] [PATCH V4] " Lai Jiangshan
2018-04-19 15:54         ` Dr. David Alan Gilbert
2018-07-02 13:10 ` [Qemu-devel] [PATCH] " Stefan Hajnoczi
2018-07-02 13:52   ` Peng Tao
2018-07-02 22:15     ` Andrea Arcangeli
2018-07-03  4:09       ` Peng Tao
2018-07-03 10:05     ` Stefan Hajnoczi
2018-07-03 15:10       ` Peng Tao
2018-07-10 13:40         ` Stefan Hajnoczi
2018-07-12 15:02           ` Peng Tao
2018-07-18 16:03             ` Stefan Hajnoczi
2018-07-02 22:01   ` Andrea Arcangeli [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=20180702220132.GA8790@redhat.com \
    --to=aarcange@redhat.com \
    --cc=armbru@redhat.com \
    --cc=bergwolf@gmail.com \
    --cc=dgilbert@redhat.com \
    --cc=gnawux@gmail.com \
    --cc=james.o.hunt@intel.com \
    --cc=jiangshanlai@gmail.com \
    --cc=mtosatti@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=quintela@redhat.com \
    --cc=sameo@linux.intel.com \
    --cc=sebastien.boeuf@intel.com \
    --cc=stefanha@gmail.com \
    --cc=xiaoguangrong.eric@gmail.com \
    --cc=xiaoguangrong@tencent.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.