All of lore.kernel.org
 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:51:57 +1000	[thread overview]
Message-ID: <444DFF4D.8050108@yahoo.com.au> (raw)
In-Reply-To: <1145961386.5282.37.camel@localhost>

Martin Schwidefsky wrote:
> On Tue, 2006-04-25 at 18:26 +1000, Nick Piggin wrote:

>>I don't think there is any beauty in this scheme, to be honest.
> 
> 
> Beauty lies in the eye of the beholder. From my point of view there is
> benefit to the method.

That's 'cause you have an s390.

> 
> 
>>I don't see why calling into the host is bad - won't it be able to
>>make better reclaim decisions? If starting IO is the wrong thing to
>>do under a hypervisor, why is it the right thing to do on bare metal?
> 
> 
> First some assumptions about the environment. We are talking about a
> paging hypervisor that runs several hundreds of guest Linux images. The
> memory is overcommited, the sum of the guest memory sizes is larger than
> the host memory by a factor of 2-3. Usually a large percentage of the
> guests memory is paged out by the hypervisor.
> 
> Both the host and the guest follow an LRU strategy. That means that the
> host will pick the oldest page from the idlest guest. Almost the same
> would happen if you call into the idlest guest to let the guest free its
> oldest page. But the catch is that the guest will touch a lot of page
> doing its vmscan operation, if that causes a single additional host i/o
> because a guest page needs to be retrieved from the host swap device,
> you are already in negative territory.

Why would most guest memory be paged out if the host reclaims by first
asking guests to reclaim, *then* paging them out?

I can understand that you observe most guest memory to be paged out
under pressure with the present scheme, but the dynamics will completely
change I think... You'll be left with shrunk guests, which you could
then mark as unreclaimable, stop asking them to reclaim, then page the
rest of their memory out from the host.

 > It does attempt to keep some memory free. But lets say 1000 guest images
 > generate a lot of memory pressure. You will run out of memory, and
 > anything that speeds up the host reclaim will improve the situation. And

I believe that, and I'm sure there are lots of really invasive things you
could do to make it even faster...

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

  reply	other threads:[~2006-04-25 10:51 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
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 [this message]
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=444DFF4D.8050108@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 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.