From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Michael S. Tsirkin" Subject: Re: [PATCHv2] KVM: optimize apic interrupt delivery Date: Wed, 12 Sep 2012 01:39:53 +0300 Message-ID: <20120911223952.GB28821@redhat.com> References: <20120911130225.GN20907@redhat.com> <20120911141023.GB26031@redhat.com> <20120911171300.GJ4257@linux.vnet.ibm.com> <504F996B.4030307@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: paulmck@linux.vnet.ibm.com, Gleb Natapov , kvm@vger.kernel.org, mtosatti@redhat.com To: Avi Kivity Return-path: Received: from mx1.redhat.com ([209.132.183.28]:32749 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751788Ab2IKWiZ (ORCPT ); Tue, 11 Sep 2012 18:38:25 -0400 Content-Disposition: inline In-Reply-To: <504F996B.4030307@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: On Tue, Sep 11, 2012 at 11:04:59PM +0300, Avi Kivity wrote: > On 09/11/2012 08:13 PM, Paul E. McKenney wrote: > > > Is there a risk of DOS if RCU is delayed while > > > lots of memory is queued up in this way? > > > If yes is this a generic problem with kfree_rcu > > > that should be addressed in core kernel? > > > > There is indeed a risk. The kfree_rcu() implementation cannot really > > decide what to do here, especially given that it is callable with irqs > > disabled. > > > > The usual approach is to keep a per-CPU counter and count it down from > > some number for each kfree_rcu(). When it reaches zero, invoke > > synchronize_rcu() as well as kfree_rcu(), and then reset it to the > > "some number" mentioned above. > > > > In theory, I could create an API that did this. In practice, I have no > > idea how to choose the number -- much depends on the size of the object > > being freed, for example. > > Perhaps approach it from the other direction? If we are under memory > pressure, start synchronize_rcu()ing, much like the shrinker operates. > Tricky ... For now, how about we call synchronize_rcu_expedited in kvm and call it a day? Also has an advantage that apic map is guaranteed to be in sync with guest - while it seems that it's already correct as is, synchronous operation is way simpler. We can add a tracepoint so that we can detect it if this starts happening a lot for some guest. > > -- > I have a truly marvellous patch that fixes the bug which this > signature is too narrow to contain.