Re: [PATCHv2] KVM: optimize apic interrupt delivery

[Avi Kivity <avi@redhat.com>]

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.



-- 
I have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.