linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Jeremy Fitzhardinge <jeremy@goop.org>
To: Martin Schwidefsky <schwidefsky@de.ibm.com>
Cc: Rik van Riel <riel@redhat.com>,
	akpm@osdl.org, Nick Piggin <nickpiggin@yahoo.com.au>,
	frankeh@watson.ibm.com, virtualization@lists.osdl.org,
	linux-kernel@vger.kernel.org,
	virtualization@lists.linux-foundation.org, linux-mm@kvack.org,
	hugh@veritas.com, Xen-devel <xen-devel@lists.xensource.com>
Subject: Re: [patch 0/6] Guest page hinting version 7.
Date: Fri, 03 Apr 2009 11:19:24 -0700	[thread overview]
Message-ID: <49D6532C.6010804@goop.org> (raw)
In-Reply-To: <20090403104913.29c62082@skybase>

Martin Schwidefsky wrote:
> This is the basic idea of guest page hinting. Let the host memory
> manager make it decision based on the data it has. That includes page
> age determined with a global LRU list, page age determined with a
> per-guest LRU list, i/o rates of the guests, all kind of policy which
> guest should have how much memory.

Do you look at fault rates?  Refault rates?

>  The page hinting comes into play
> AFTER the decision has been made which page to evict. Only then the host
> should look at the volatile vs. stable page state and decide what has
> to be done with the page. If it is volatile the host can throw the page
> away because the guest can recreate it with LESS effort. That is the
> optimization.
>   

Yes, and its good from that perspective.   Do you really implement it 
purely that way, or do you bias the LRU to push volatile and free pages 
down the end of the LRU list in preference to pages which must be 
preserved?  If you have a small bias then you can prefer to evict easily 
evictable pages compared to their near-equivalents which require IO.

> But with page hinting you don't have to even ask. Just take the pages
> if you need them. The guest already told you that you can have them by
> setting the unused state.
>   

Yes.  But it still depends on the guest.  A very helpful guest could 
deliberately preswap pages so that it can mark them as volatile, whereas 
a less helpful one may keep them persistent and defer preswapping them 
until there's a good reason to do so.  Host swapping and page hinting 
won't put any apparent memory pressure on the guest, so it has no reason 
to start preswapping even if the overall system is under pressure.  
Ballooning will expose each guest to its share of the overall system 
memory pressure, so they can respond appropriately (one hopes).

    J

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

  reply	other threads:[~2009-04-03 18:19 UTC|newest]

Thread overview: 52+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-03-27 15:09 Martin Schwidefsky
2009-03-27 15:09 ` [patch 1/6] Guest page hinting: core + volatile page cache Martin Schwidefsky
2009-03-27 22:57   ` Rik van Riel
2009-03-29 13:56     ` Martin Schwidefsky
2009-03-29 14:35       ` Rik van Riel
2009-03-27 15:09 ` [patch 2/6] Guest page hinting: volatile swap cache Martin Schwidefsky
2009-04-01  2:10   ` Rik van Riel
2009-04-01  8:13     ` Martin Schwidefsky
2009-03-27 15:09 ` [patch 3/6] Guest page hinting: mlocked pages Martin Schwidefsky
2009-04-01  2:52   ` Rik van Riel
2009-04-01  8:13     ` Martin Schwidefsky
2009-03-27 15:09 ` [patch 4/6] Guest page hinting: writable page table entries Martin Schwidefsky
2009-04-01 13:25   ` Rik van Riel
2009-04-01 14:36     ` Martin Schwidefsky
2009-04-01 14:45       ` Rik van Riel
2009-03-27 15:09 ` [patch 5/6] Guest page hinting: minor fault optimization Martin Schwidefsky
2009-04-01 15:33   ` Rik van Riel
2009-03-27 15:09 ` [patch 6/6] Guest page hinting: s390 support Martin Schwidefsky
2009-04-01 16:18   ` Rik van Riel
2009-03-27 23:03 ` [patch 0/6] Guest page hinting version 7 Dave Hansen
2009-03-28  0:06   ` Rik van Riel
2009-03-29 14:20     ` Martin Schwidefsky
2009-03-29 14:38       ` Rik van Riel
2009-03-29 14:12   ` Martin Schwidefsky
2009-03-30 15:54     ` Dave Hansen
2009-03-30 16:34       ` Martin Schwidefsky
2009-03-30 18:37       ` Jeremy Fitzhardinge
2009-03-30 18:42         ` Rik van Riel
2009-03-30 18:59           ` Jeremy Fitzhardinge
2009-03-30 20:02             ` Rik van Riel
2009-03-30 20:35               ` Jeremy Fitzhardinge
2009-03-30 21:38                 ` Dor Laor
2009-03-30 22:16                   ` Izik Eidus
2009-03-28  6:35 ` Rusty Russell
2009-03-29 14:23   ` Martin Schwidefsky
2009-04-02 11:32     ` Nick Piggin
2009-04-02 15:52       ` Martin Schwidefsky
2009-04-02 16:18         ` Jeremy Fitzhardinge
2009-04-02 16:23         ` Nick Piggin
2009-04-02 19:06         ` Rik van Riel
2009-04-02 19:22           ` Nick Piggin
2009-04-02 20:05             ` Rik van Riel
2009-04-03  0:50               ` Jeremy Fitzhardinge
2009-04-02 19:58           ` Jeremy Fitzhardinge
2009-04-02 20:14             ` Rik van Riel
2009-04-02 20:34               ` Jeremy Fitzhardinge
2009-04-03  8:49                 ` Martin Schwidefsky
2009-04-03 18:19                   ` Jeremy Fitzhardinge [this message]
2009-04-06  7:21                     ` Martin Schwidefsky
2009-04-06  7:32                       ` Nick Piggin
2009-04-06 19:23                       ` Jeremy Fitzhardinge
2009-04-02 19:27         ` Hugh Dickins

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=49D6532C.6010804@goop.org \
    --to=jeremy@goop.org \
    --cc=akpm@osdl.org \
    --cc=frankeh@watson.ibm.com \
    --cc=hugh@veritas.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=nickpiggin@yahoo.com.au \
    --cc=riel@redhat.com \
    --cc=schwidefsky@de.ibm.com \
    --cc=virtualization@lists.linux-foundation.org \
    --cc=virtualization@lists.osdl.org \
    --cc=xen-devel@lists.xensource.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