linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Nick Piggin <nickpiggin@yahoo.com.au>
To: schwidefsky@de.ibm.com
Cc: Andrew Morton <akpm@osdl.org>,
	linux-mm@kvack.org, frankeh@watson.ibm.com, rhim@cc.gatech.edu
Subject: Re: Page host virtual assist patches.
Date: Tue, 25 Apr 2006 20:04:55 +1000	[thread overview]
Message-ID: <444DF447.4020306@yahoo.com.au> (raw)
In-Reply-To: <1145953914.5282.21.camel@localhost>

Martin Schwidefsky wrote:

> The point here is WHO does the reclaim. Sure we can do the reclaim in
> the guest but it is the host that has the memory pressure. To call into

By logic, if the host has memory pressure, and the guest is running on
the host, doesn't the guest have memory pressure? (Assuming you want to
reclaim guest pages, which you do because that is what your patches are
effectively doing anyway).

If the guest isn't under memory pressure (it has been allocated a fixed
amount of memory, and hasn't exceeded it), then you just don't call in.
Nor should you be employing this virtual assist reclaim on them.

> the guest is not a good idea, if you have an idle guest you generally
> increase the memory pressure because some of the guests pages might have
> been swapped which are needed if the guest has to do the reclaim. 

It might be a win in heavy swapping conditions to get your hypervisor's
tentacles into the guests' core VM, I could believe that. Doesn't mean
it is a good idea in our purpose OS.

How badly did the simple approach fare?

-- 
SUSE Labs, Novell Inc.

Send instant messages to your online friends http://au.messenger.yahoo.com 

--
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>

  parent reply	other threads:[~2006-04-25 10:04 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-04-24 12:34 Page host virtual assist patches Martin Schwidefsky
2006-04-25  1:01 ` Andrew Morton
2006-04-25  7:19   ` Nick Piggin
2006-04-25  8:31     ` Martin Schwidefsky
2006-04-25  8:37       ` Andrew Morton
2006-04-25 10:44         ` Martin Schwidefsky
2006-04-25 16:29           ` Andrew Morton
2006-04-25 17:04             ` Martin Schwidefsky
2006-04-25 10:04       ` Nick Piggin [this message]
2006-04-25 11:28         ` Martin Schwidefsky
2006-04-25 12:13           ` Nick Piggin
2006-04-25 14:15             ` Martin Schwidefsky
2006-04-26  1:13               ` Nick Piggin
2006-04-26  7:39                 ` Martin Schwidefsky
2006-04-26 12:03                   ` Hubertus Franke
2006-04-27 20:55           ` jschopp
2006-04-25  8:10   ` Martin Schwidefsky
2006-04-25  8:26     ` Nick Piggin
2006-04-25 10:36       ` Martin Schwidefsky
2006-04-25 10:51         ` Nick Piggin
2006-04-25 12:18           ` Martin Schwidefsky
2006-04-25  8:30     ` Andrew Morton
2006-04-25 10:43       ` Martin Schwidefsky

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=444DF447.4020306@yahoo.com.au \
    --to=nickpiggin@yahoo.com.au \
    --cc=akpm@osdl.org \
    --cc=frankeh@watson.ibm.com \
    --cc=linux-mm@kvack.org \
    --cc=rhim@cc.gatech.edu \
    --cc=schwidefsky@de.ibm.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).