From: Dave Hansen <dave@linux.vnet.ibm.com>
To: Rik van Riel <riel@redhat.com>
Cc: John Stultz <john.stultz@linaro.org>,
LKML <linux-kernel@vger.kernel.org>,
Robert Love <rlove@google.com>,
Christoph Hellwig <hch@infradead.org>,
Andrew Morton <akpm@linux-foundation.org>,
Hugh Dickins <hughd@google.com>, Mel Gorman <mel@csn.ul.ie>,
Eric Anholt <eric@anholt.net>,
Jesse Barnes <jbarnes@virtuousgeek.org>,
Johannes Weiner <jweiner@redhat.com>,
Jon Masters <jcm@redhat.com>
Subject: Re: [PATCH] [RFC] fadvise: Add _VOLATILE,_ISVOLATILE, and _NONVOLATILE flags
Date: Tue, 22 Nov 2011 12:39:28 -0800 [thread overview]
Message-ID: <4ECC0880.8050203@linux.vnet.ibm.com> (raw)
In-Reply-To: <4ECB7D48.6080307@redhat.com>
On 11/22/2011 02:45 AM, Rik van Riel wrote:
> 4) Virtualization. Marking an object (and its pages)
> _VOLATILE inside a guest will not be visible on the
> host side, which means a virtual system may continue
> to suffer the performance penalty anyway.
Yeah, I guess we still have to communicate it _somehow_.
I guess we could theoretically pass the calls up to the
hypervisor and it could even make its own VOLATILE calls
to the host kernel. We'd also have to pass back down the
"was this evicted" information during a re-pin. That seems
messy to me.
Is it really any different of a problem than page cache?
The guest has data sitting in RAM that it probably doesn't
need. If we passed up just the amount of unpinned data back
up to the hypervisor, it would have a decent idea how much
it could balloon the guest, for instance. That would fit
in well with some of the existing schemes that folks have
and be *much* nicer than what they've got at the moment.
next prev parent reply other threads:[~2011-11-22 20:40 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-11-22 3:33 [PATCH] [RFC] fadvise: Add _VOLATILE,_ISVOLATILE, and _NONVOLATILE flags John Stultz
2011-11-22 9:37 ` Rik van Riel
2011-11-22 10:45 ` Rik van Riel
2011-11-22 20:39 ` Dave Hansen [this message]
2011-11-22 16:31 ` Robert Love
2011-11-22 19:48 ` John Stultz
2011-11-23 0:27 ` Rik van Riel
[not found] ` <CAG6tG3xTkW1J=6xmUmmJoswJyR6ii5RDXvAsYrcH0CkVuUmJrQ@mail.gmail.com>
2011-11-23 0:39 ` Rik van Riel
2011-11-23 15:52 ` Robert Love
2011-11-26 0:05 ` Jan Kara
2011-11-22 20:52 ` Andrew Morton
2011-11-22 21:32 ` John Stultz
2011-11-22 21:39 ` Andrew Morton
2011-11-22 22:58 ` John Stultz
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=4ECC0880.8050203@linux.vnet.ibm.com \
--to=dave@linux.vnet.ibm.com \
--cc=akpm@linux-foundation.org \
--cc=eric@anholt.net \
--cc=hch@infradead.org \
--cc=hughd@google.com \
--cc=jbarnes@virtuousgeek.org \
--cc=jcm@redhat.com \
--cc=john.stultz@linaro.org \
--cc=jweiner@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mel@csn.ul.ie \
--cc=riel@redhat.com \
--cc=rlove@google.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