All of lore.kernel.org
 help / color / mirror / Atom feed
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>

  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 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
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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.