From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate4.de.ibm.com (8.13.6/8.13.6) with ESMTP id k3PBSlIi140014 for ; Tue, 25 Apr 2006 11:28:47 GMT Received: from d12av02.megacenter.de.ibm.com (d12av02.megacenter.de.ibm.com [9.149.165.228]) by d12nrmr1607.megacenter.de.ibm.com (8.12.10/NCO/VER6.8) with ESMTP id k3PBTqKp122786 for ; Tue, 25 Apr 2006 13:29:52 +0200 Received: from d12av02.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av02.megacenter.de.ibm.com (8.12.11/8.13.3) with ESMTP id k3PBSkt2025826 for ; Tue, 25 Apr 2006 13:28:46 +0200 Subject: Re: Page host virtual assist patches. From: Martin Schwidefsky Reply-To: schwidefsky@de.ibm.com In-Reply-To: <444DF447.4020306@yahoo.com.au> References: <20060424123412.GA15817@skybase> <20060424180138.52e54e5c.akpm@osdl.org> <444DCD87.2030307@yahoo.com.au> <1145953914.5282.21.camel@localhost> <444DF447.4020306@yahoo.com.au> Content-Type: text/plain Date: Tue, 25 Apr 2006 13:28:51 +0200 Message-Id: <1145964531.5282.59.camel@localhost> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: owner-linux-mm@kvack.org Return-Path: To: Nick Piggin Cc: Andrew Morton , linux-mm@kvack.org, frankeh@watson.ibm.com, rhim@cc.gatech.edu List-ID: 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: email@kvack.org