qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: "Ritchie, Stuart" <Stuart.Ritchie@tellabs.com>
To: Stefan Hajnoczi <stefanha@gmail.com>, Brad Hards <bradh@frogmouth.net>
Cc: "qemu-devel@nongnu.org" <qemu-devel@nongnu.org>
Subject: Re: [Qemu-devel] Para-virtualized ram-based filesystem?
Date: Sun, 17 Apr 2011 23:12:16 -0500	[thread overview]
Message-ID: <C9D0FEE6.BBC9%Stuart.Ritchie@tellabs.com> (raw)
In-Reply-To: <BANLkTin9uuAx7=X54L8D99+V_AiqHR_U4w@mail.gmail.com>

On 4/16/11 1:52 AM, "Stefan Hajnoczi" <stefanha@gmail.com> wrote:

>On Sat, Apr 16, 2011 at 1:27 AM, Brad Hards <bradh@frogmouth.net> wrote:
>> On Saturday 16 April 2011 09:58:32 Ritchie, Stuart wrote:
>>> How does that sound?
>> As a general user: Confusing.
>>
>> Is there a concrete example (specific applications, specific
>>performance issues,
>> specific requirements) that you can share?
>
>I'm also wondering why you want this.

The reason why we want this is the same reason why anyone would want
mmap() and tmpfs/ramfs in the first place: zero-copy, in-place access to
your data.

>
>Does it matter if the files get pushed out to swap on the host?

We don't run in a swapping environment.  But someone who does and accepts
the performance hit, then I don't see why it would matter.

Ramfs does not kick pages out of the page-cache.  But tmpfs does -- the
host should make this transparent, as it does now.

>
>It's tempting to take advantage of running virtualized but then things
>like migration get in the way.  Have you actually tried out network
>file systems and determined they won't work for some reason?
>
>Stefan

For performance reasons it's very important for our system that the data
be as close to the app as possible.  We can't afford to push data through
an I/O channel.

What I'm really suggesting here is a way for guest applications to mmap()
host memory.

Combine that with a virt-aware robust mutex and you've probably got the
most flexible, performant, inter-guest sharing/communication mechanism
possible.  (Semaphores through a socket?  On the same system?  You gotta
be kidding. :-)

Cheers,
--Stuart


============================================================
The information contained in this message may be privileged
and confidential and protected from disclosure. If the reader
of this message is not the intended recipient, or an employee
or agent responsible for delivering this message to the
intended recipient, you are hereby notified that any reproduction,
dissemination or distribution of this communication is strictly
prohibited. If you have received this communication in error,
please notify us immediately by replying to the message and
deleting it from your computer. Thank you. Tellabs
============================================================

  parent reply	other threads:[~2011-04-18  4:12 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-04-15 21:09 [Qemu-devel] Para-virtualized ram-based filesystem? Ritchie, Stuart
2011-04-15 21:43 ` Anthony Liguori
2011-04-15 23:58   ` Ritchie, Stuart
2011-04-16  0:27     ` Brad Hards
2011-04-16  8:52       ` Stefan Hajnoczi
2011-04-16  8:54         ` Stefan Hajnoczi
2011-04-18  4:12         ` Ritchie, Stuart [this message]
2011-04-17 12:43     ` Avi Kivity
2011-04-18  3:28       ` Ritchie, Stuart
2011-04-18  6:31         ` Avi Kivity

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=C9D0FEE6.BBC9%Stuart.Ritchie@tellabs.com \
    --to=stuart.ritchie@tellabs.com \
    --cc=bradh@frogmouth.net \
    --cc=qemu-devel@nongnu.org \
    --cc=stefanha@gmail.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;
as well as URLs for NNTP newsgroup(s).