Re: Page host virtual assist patches.

[Martin Schwidefsky <schwidefsky@de.ibm.com>]

On Tue, 2006-04-25 at 01:30 -0700, Andrew Morton wrote:
> > > This is pretty significant stuff.  It sounds like something which needs to
> > > be worked through with other possible users - UML, Xen, vware, etc.
> > > 
> > > How come the reclaim has to be done in the host?  I'd have thought that a
> > > much simpler approach would be to perform a host->guest upcall saying
> > > either "try to free up this many pages" or "free this page" or "free this
> > > vector of pages"?
> > 
> > Because calling into the guest is too slow.
> 
> So speed it up ;)

We did.. the other way round by adding the ESSA :-)

> > You need to schedule a cpu,
> > the code that does the allocation needs to run, which might need other
> > pages, etc. The beauty of the scheme is that the host can immediately
> > remove a page that is mark as volatile or unused. No i/o, no scheduling,
> > nothing. Consider what that does to the latency of the hosts memory
> > allocation. Even if the percentage of discardable pages is small, lets
> > say 25% of the guests memory, the host will quickly find reusable
> > memory. If the vmscan of the host attempts to evict 100 pages, on
> > average it will start i/o for 75 of them, the other 25 are immediately
> > free for reuse.
> 
> Batching can do wonders.  What's the expected/typical memory footprint of a
> guest versus the machine's total physical memory?

Yes, batching will speed up the calls for one particular guest. Trouble
is that we are not talking about freeing 1000 pages from 1 guest. We
have the problem to free 1 page from 1000 guests.

> And what's the typical total size of a guest?
> 
> Because a 100-page chunk sounds an awfully small work unit for a guest, let
> alone for the host.

The typical memory size of the guests depends on the workload it runs. A
typical memory size would be something like 256MB. The real catch is the
amount of memory overcommitment. And 100 pages sound about right if you
have 1000 guests.

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