From mboxrd@z Thu Jan 1 00:00:00 1970 From: Takuya Yoshikawa Subject: Re: [PATCH 4/4] KVM: MMU: Make mmu_shrink() scan nr_to_scan shadow pages Date: Mon, 19 Dec 2011 18:22:31 +0900 Message-ID: <4EEF0257.9090507@oss.ntt.co.jp> References: <20111212072242.8aaf64a3420608b8204702c7@gmail.com> <20111212072647.1990b19483b0a482a894a0f6@gmail.com> <20111216110611.GC26982@amt.cnet> <20111216235824.a8016959785b2bd869b84a0a@gmail.com> <4EEEF92F.9020807@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Takuya Yoshikawa , Marcelo Tosatti , kvm@vger.kernel.org To: Avi Kivity Return-path: Received: from serv2.oss.ntt.co.jp ([222.151.198.100]:40266 "EHLO serv2.oss.ntt.co.jp" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751629Ab1LSJVX (ORCPT ); Mon, 19 Dec 2011 04:21:23 -0500 In-Reply-To: <4EEEF92F.9020807@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: (2011/12/19 17:43), Avi Kivity wrote: > Well, if one guest is twice as large as other guests, then it will want > twice as many shadow pages. So our goal should be to zap pages from the > guest with the highest (shadow pages / memory) ratio. > >>> >>> Can you measure whether there is a significant difference in a synthetic >>> workload, and what that change is? Perhaps apply {moderate, high} memory >>> pressure load with {2, 4, 8, 16} VMs or something like that. >>> >> >> I was running 4 VMs on my machine with enough high memory pressure. The problem >> was that mmu_shrink() was not tuned to be called in usual memory pressures: what >> I did was changing the seeks and batch parameters and making ept=0. >> >> At least, I have checked that if I make one VM do meaningless many copies, letting >> others keep silent, the shrinker frees shadow pages intensively from that one. >> >> >> Anyway, I don't think making the shrinker call mmu_shrink() with the default batch >> size, nr_to_scan=128, and just trying to free one shadow page is a good behaviour. > > Yes, it's very conservative. But on the other hand the shrinker is > tuned for dcache and icache, where there are usually tons of useless > objects. If we have to free something, I'd rather free them instead of > mmu pages which tend to get recreated soon. > OK, to satisfy the requirements, I will do: 1. find the guest with the highest (shadow pages / memory) ratio 2. just zap one page from that guest, keeping the current conservative rate I will update the patch. Takuya