From: Martin Schwidefsky <schwidefsky@de.ibm.com>
To: Nick Piggin <nickpiggin@yahoo.com.au>
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 13:28:51 +0200 [thread overview]
Message-ID: <1145964531.5282.59.camel@localhost> (raw)
In-Reply-To: <444DF447.4020306@yahoo.com.au>
On Tue, 2006-04-25 at 20:04 +1000, Nick Piggin wrote:
> 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).
The memory pressure of the host is generated by the guests. But the
guest that has to give up memory in general is NOT the guest that is
currently running. And no, the running guest system does not have memory
pressure since its "real" memory is virtualized by the host. The guest
simply accesses the virtual page frames. If the host has paged them, the
host gets the exception and has to deal with it.
> 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 guests have a fixed host-virtual memory size. They do not have a
fixed host-physical memory size. And for an idle guest we will reclaim
old pages from it until nothing remains of the guest in memory.
> > 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.
Yes, we do heavy swapping in the hypervisor. For a purpose OS it is not
a good idea but then done set CONFIG_PAGE_HVA and all the hva code turns
into nops.
> How badly did the simple approach fare?
Which simple approach do you mean? The guest ballooner? That works
reasonably well for a small number of guests. If you keep adding guests
the overhead for the guest calls increases. Ultimately we believe that a
combination of the ballooner method and the new hva method will yield
the best results.
--
blue skies,
Martin.
Martin Schwidefsky
Linux for zSeries Development & Services
IBM Deutschland Entwicklung GmbH
"Reality continues to ruin my life." - Calvin.
--
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>
next prev parent reply other threads:[~2006-04-25 11:29 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-04-24 12:34 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
2006-04-25 11:28 ` Martin Schwidefsky [this message]
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=1145964531.5282.59.camel@localhost \
--to=schwidefsky@de.ibm.com \
--cc=akpm@osdl.org \
--cc=frankeh@watson.ibm.com \
--cc=linux-mm@kvack.org \
--cc=nickpiggin@yahoo.com.au \
--cc=rhim@cc.gatech.edu \
/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