On Thu, Oct 10, 2013 at 03:08:45PM +0300, Gleb Natapov wrote: > 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, Correct, but that limit is not suitable (maximum number of mmu pages should be larger than number of mmu pages freeable in a rcu grace period). > and, in addition, page released to slab is immediately > available for allocation, no need to wait for grace period. See SLAB_DESTROY_BY_RCU comment at include/linux/slab.h. > 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. Agree. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
