Re: [PATCHv2] KVM: optimize apic interrupt delivery

[Gleb Natapov <gleb@redhat.com>]

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.