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 16:15:21 +0200 [thread overview]
Message-ID: <1145974521.5282.89.camel@localhost> (raw)
In-Reply-To: <444E1253.9090302@yahoo.com.au>
On Tue, 2006-04-25 at 22:13 +1000, Nick Piggin wrote:
> >>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.
>
> That's just arguing semantics now. You are advocating to involve guests
> in cooperating with memory management with the host. Ergo, if there is
> memory pressure in the host then it is not a "layering violation" to ask
> guests to reclaim memory as if they were under memory pressure too.
>
> No more a violation than having the host reclaim the guest's memory from
> under it.
I wouldn't call it a violation. But yes both ways of doing achieve the
same result. One of the guest pages is reclaimed. The million dollar
question is which way is faster.
> > 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.
>
> But anybody who modifies or tries to understand the code and races etc
> involved has to know about all this stuff. That is my problem with it.
Oh, yes, I perfectly understand this. The code is rather complex.
> I'm not worried about the overhead at all, because I presume you have
> made it zero for the !CONFIG_PAGE_HVA case.
Yes, we made sure of that.
> > 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.
>
> Yes, that simple approach (presumably the guest ballooner allocates
> memory from the guest and frees it to the host or something similar).
> I'd be interested to see numbers from real workloads...
>
> I don't think the hva method is reasonable as it is. Let's see if we
> can improve host->guest driven reclaiming first.
So you believe that the host->guest driven relaiming can be improved to
a point where hva is superfluous. I do not believe that. Lets agree to
disagree here. Any findings in the hva code itself?
Anyway, thanks for you insights.
--
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 14:16 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
2006-04-25 12:13 ` Nick Piggin
2006-04-25 14:15 ` Martin Schwidefsky [this message]
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=1145974521.5282.89.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