Re: Page host virtual assist patches.

[Nick Piggin <nickpiggin@yahoo.com.au>]

Martin Schwidefsky wrote:
> 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.

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.

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

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.

I'm not worried about the overhead at all, because I presume you have
made it zero for the !CONFIG_PAGE_HVA case.

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

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.

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