From mboxrd@z Thu Jan 1 00:00:00 1970 From: Gleb Natapov Subject: Re: [PATCHv2] KVM: optimize apic interrupt delivery Date: Wed, 12 Sep 2012 15:44:26 +0300 Message-ID: <20120912124426.GR20907@redhat.com> References: <20120911130225.GN20907@redhat.com> <20120911141023.GB26031@redhat.com> <20120911171300.GJ4257@linux.vnet.ibm.com> <20120911223337.GA28821@redhat.com> <20120912010334.GK4257@linux.vnet.ibm.com> <50503D92.7090108@redhat.com> <20120912123441.GQ20907@redhat.com> <505081E9.8080505@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: paulmck@linux.vnet.ibm.com, "Michael S. Tsirkin" , kvm@vger.kernel.org, mtosatti@redhat.com To: Avi Kivity Return-path: Received: from mx1.redhat.com ([209.132.183.28]:19142 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757566Ab2ILMof (ORCPT ); Wed, 12 Sep 2012 08:44:35 -0400 Content-Disposition: inline In-Reply-To: <505081E9.8080505@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: On Wed, Sep 12, 2012 at 03:36:57PM +0300, Avi Kivity wrote: > On 09/12/2012 03:34 PM, Gleb Natapov wrote: > > On Wed, Sep 12, 2012 at 10:45:22AM +0300, Avi Kivity wrote: > >> On 09/12/2012 04:03 AM, Paul E. McKenney wrote: > >> >> > > Paul, I'd like to check something with you here: > >> >> > > this function can be triggered by userspace, > >> >> > > any number of times; we allocate > >> >> > > a 2K chunk of memory that is later freed by > >> >> > > kfree_rcu. > >> >> > > > >> >> > > 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. > >> >> > >> >> In our case it's a 2K object. Is it a practical risk? > >> > > >> > How many kfree_rcu()s per second can a given user cause to happen? > >> > >> Not much more than a few hundred thousand per second per process (normal > >> operation is zero). > >> > > I managed to do 21466 per second. > > Strange, why so slow? > Because ftrace buffer overflows :) With bigger buffer I get 169940. > >> Good idea. Michael, is should be easy to modify kvm-unit-tests to write > >> to the APIC ID register in a loop. > >> > > I did. Memory consumption does not grow on otherwise idle host. > > Ok, thanks. > > > -- > error compiling committee.c: too many arguments to function -- Gleb.