From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: [patch 07/10] KVM: introduce kvm->srcu and convert kvm_set_memory_region to SRCU update Date: Fri, 25 Sep 2009 18:05:25 +0300 Message-ID: <4ABCDC35.7070406@redhat.com> References: <20090921233711.213665413@amt.cnet> <20090921234124.596305294@amt.cnet> <20090924140651.GA13623@amt.cnet> <20090924172841.GC6265@linux.vnet.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Marcelo Tosatti , kvm@vger.kernel.org To: paulmck@linux.vnet.ibm.com Return-path: Received: from mx1.redhat.com ([209.132.183.28]:19165 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752839AbZIYPF1 (ORCPT ); Fri, 25 Sep 2009 11:05:27 -0400 In-Reply-To: <20090924172841.GC6265@linux.vnet.ibm.com> Sender: kvm-owner@vger.kernel.org List-ID: On 09/24/2009 08:28 PM, Paul E. McKenney wrote: > >> Each synchronize_srcu() call takes about 10ms (avg 3ms per >> synchronize_sched call), so this is hurting us. >> >> Is this expected? Is there any possibility for synchronize_srcu() >> optimization? >> >> There are other sides we can work on, such as reducing the memory slot >> updates, but i'm wondering what can be done regarding SRCU itself. >> > This is expected behavior, but there is a possible fix currently > in mainline (Linus's git tree). The idea would be to create a > synchronize_srcu_expedited(), which starts with synchronize_srcu(), and > replaces the synchronize_sched() calls with synchronize_sched_expedited(). > > This could potentially reduce the overall synchronize_srcu() latency > to well under a microsecond. The price to be paid is that each instance > of synchronize_sched_expedited() IPIs all the online CPUs, and awakens > the migration thread on each. > > Would this approach likely work for you? > It's perfect. -- Do not meddle in the internals of kernels, for they are subtle and quick to panic.