From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Date: Mon, 28 Jun 2010 13:30:49 +0000 Subject: Re: [PATCH] KVM: PPC: Add generic hpte management functions Message-Id: <4C28A409.9090207@redhat.com> List-Id: References: <1277507817-626-1-git-send-email-agraf@suse.de> <1277507817-626-2-git-send-email-agraf@suse.de> <4C285D1C.5060508@redhat.com> <20417D40-9345-485B-9201-8B3722B7457F@suse.de> <4C286770.6010204@redhat.com> <1A0E0E54-D055-4333-B5EC-DE2F71382AB7@suse.de> <4C286C98.8060903@redhat.com> <4C2871A8.1060706@suse.de> <4C2872F5.20501@redhat.com> <4C28A2C1.50700@suse.de> In-Reply-To: <4C28A2C1.50700@suse.de> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: Alexander Graf Cc: "kvm-ppc@vger.kernel.org" , KVM list , linuxppc-dev On 06/28/2010 04:25 PM, Alexander Graf wrote: >> >>>> Less and simpler code, better reporting through slabtop, less wastage >>>> of partially allocated slab pages. >>>> >>>> >>> But it also means that one VM can spill the global slab cache and kill >>> another VM's mm performance, no? >>> >>> >> What do you mean by spill? >> Well? >> btw, in the midst of the nit-picking frenzy I forgot to ask how the >> individual hash chain lengths as well as the per-vm allocation were >> limited. >> >> On x86 we have a per-vm limit and we allow the mm shrinker to reduce >> shadow mmu data structures dynamically. >> >> > Very simple. I keep an int with the number of allocated entries around > and if that hits a define'd threshold, I flush all shadow pages. > A truly nefarious guest will make all ptes hash to the same chain, making some operations very long (O(n^2) in the x86 mmu, don't know about ppc) under a spinlock. So we had to limit hash chains, not just the number of entries. But your mmu is per-cpu, no? In that case, no spinlock, and any damage the guest does is limited to itself. -- error compiling committee.c: too many arguments to function From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by ozlabs.org (Postfix) with ESMTP id DDA1DB6F01 for ; Mon, 28 Jun 2010 23:30:53 +1000 (EST) Message-ID: <4C28A409.9090207@redhat.com> Date: Mon, 28 Jun 2010 16:30:49 +0300 From: Avi Kivity MIME-Version: 1.0 To: Alexander Graf Subject: Re: [PATCH] KVM: PPC: Add generic hpte management functions References: <1277507817-626-1-git-send-email-agraf@suse.de> <1277507817-626-2-git-send-email-agraf@suse.de> <4C285D1C.5060508@redhat.com> <20417D40-9345-485B-9201-8B3722B7457F@suse.de> <4C286770.6010204@redhat.com> <1A0E0E54-D055-4333-B5EC-DE2F71382AB7@suse.de> <4C286C98.8060903@redhat.com> <4C2871A8.1060706@suse.de> <4C2872F5.20501@redhat.com> <4C28A2C1.50700@suse.de> In-Reply-To: <4C28A2C1.50700@suse.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Cc: linuxppc-dev , KVM list , "kvm-ppc@vger.kernel.org" List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , On 06/28/2010 04:25 PM, Alexander Graf wrote: >> >>>> Less and simpler code, better reporting through slabtop, less wastage >>>> of partially allocated slab pages. >>>> >>>> >>> But it also means that one VM can spill the global slab cache and kill >>> another VM's mm performance, no? >>> >>> >> What do you mean by spill? >> Well? >> btw, in the midst of the nit-picking frenzy I forgot to ask how the >> individual hash chain lengths as well as the per-vm allocation were >> limited. >> >> On x86 we have a per-vm limit and we allow the mm shrinker to reduce >> shadow mmu data structures dynamically. >> >> > Very simple. I keep an int with the number of allocated entries around > and if that hits a define'd threshold, I flush all shadow pages. > A truly nefarious guest will make all ptes hash to the same chain, making some operations very long (O(n^2) in the x86 mmu, don't know about ppc) under a spinlock. So we had to limit hash chains, not just the number of entries. But your mmu is per-cpu, no? In that case, no spinlock, and any damage the guest does is limited to itself. -- error compiling committee.c: too many arguments to function From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: [PATCH] KVM: PPC: Add generic hpte management functions Date: Mon, 28 Jun 2010 16:30:49 +0300 Message-ID: <4C28A409.9090207@redhat.com> References: <1277507817-626-1-git-send-email-agraf@suse.de> <1277507817-626-2-git-send-email-agraf@suse.de> <4C285D1C.5060508@redhat.com> <20417D40-9345-485B-9201-8B3722B7457F@suse.de> <4C286770.6010204@redhat.com> <1A0E0E54-D055-4333-B5EC-DE2F71382AB7@suse.de> <4C286C98.8060903@redhat.com> <4C2871A8.1060706@suse.de> <4C2872F5.20501@redhat.com> <4C28A2C1.50700@suse.de> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "kvm-ppc@vger.kernel.org" , KVM list , linuxppc-dev To: Alexander Graf Return-path: Received: from mx1.redhat.com ([209.132.183.28]:42302 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751395Ab0F1Na4 (ORCPT ); Mon, 28 Jun 2010 09:30:56 -0400 In-Reply-To: <4C28A2C1.50700@suse.de> Sender: kvm-owner@vger.kernel.org List-ID: On 06/28/2010 04:25 PM, Alexander Graf wrote: >> >>>> Less and simpler code, better reporting through slabtop, less wastage >>>> of partially allocated slab pages. >>>> >>>> >>> But it also means that one VM can spill the global slab cache and kill >>> another VM's mm performance, no? >>> >>> >> What do you mean by spill? >> Well? >> btw, in the midst of the nit-picking frenzy I forgot to ask how the >> individual hash chain lengths as well as the per-vm allocation were >> limited. >> >> On x86 we have a per-vm limit and we allow the mm shrinker to reduce >> shadow mmu data structures dynamically. >> >> > Very simple. I keep an int with the number of allocated entries around > and if that hits a define'd threshold, I flush all shadow pages. > A truly nefarious guest will make all ptes hash to the same chain, making some operations very long (O(n^2) in the x86 mmu, don't know about ppc) under a spinlock. So we had to limit hash chains, not just the number of entries. But your mmu is per-cpu, no? In that case, no spinlock, and any damage the guest does is limited to itself. -- error compiling committee.c: too many arguments to function