Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754851Ab3JJMIy (ORCPT ); Thu, 10 Oct 2013 08:08:54 -0400 Received: from mx1.redhat.com ([209.132.183.28]:9430 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753980Ab3JJMIt (ORCPT ); Thu, 10 Oct 2013 08:08:49 -0400 Date: Thu, 10 Oct 2013 15:08:45 +0300 From: Gleb Natapov To: Marcelo Tosatti Cc: Xiao Guangrong , Xiao Guangrong , avi.kivity@gmail.com, pbonzini@redhat.com, linux-kernel@vger.kernel.org, kvm@vger.kernel.org Subject: Re: [PATCH v2 12/15] KVM: MMU: allow locklessly access shadow page table out of vcpu thread Message-ID: <20131010120845.GT3574@redhat.com> References: <1378376958-27252-1-git-send-email-xiaoguangrong@linux.vnet.ibm.com> <1378376958-27252-13-git-send-email-xiaoguangrong@linux.vnet.ibm.com> <20131008012355.GA3588@amt.cnet> <20131009015627.GA4816@amt.cnet> <525533DB.1060104@gmail.com> <20131010014710.GA2198@amt.cnet> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20131010014710.GA2198@amt.cnet> Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1897 Lines: 47 On Wed, Oct 09, 2013 at 10:47:10PM -0300, Marcelo Tosatti wrote: > > >> Gleb has a idea that uses RCU_DESTORY to protect the shadow page table > > >> and encodes the page-level into the spte (since we need to check if the spte > > >> is the last-spte. ). How about this? > > > > > > Pointer please? Why is DESTROY_SLAB_RCU any safer than call_rcu with > > > regards to limitation? (maybe it is). > > > > For my experience, freeing shadow page and allocing shadow page are balanced, > > we can check it by (make -j12 on a guest with 4 vcpus and): > > > > # echo > trace > > [root@eric-desktop tracing]# cat trace > ~/log | sleep 3 > > [root@eric-desktop tracing]# cat ~/log | grep new | wc -l > > 10816 > > [root@eric-desktop tracing]# cat ~/log | grep prepare | wc -l > > 10656 > > [root@eric-desktop tracing]# cat set_event > > kvmmmu:kvm_mmu_get_page > > kvmmmu:kvm_mmu_prepare_zap_page > > > > alloc VS. free = 10816 : 10656 > > > > So that, mostly all allocing and freeing are done in the slab's > > cache and the slab frees shdadow pages very slowly, there is no rcu issue. > > A more detailed test case would be: > > - cpu0-vcpu0 releasing pages as fast as possible > - cpu1 executing get_dirty_log > > Think of a very large guest. > The number of shadow pages allocated from slab will be bounded by n_max_mmu_pages, and, in addition, page released to slab is immediately available for allocation, no need to wait for grace period. RCU comes into play only when slab is shrunk, which should be almost never. If SLAB_DESTROY_BY_RCU slab does not rate limit how it frees its pages this is for slab to fix, not for its users. -- Gleb. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/