On 09/12/2012 01:39 AM, Michael S. Tsirkin wrote: > 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? I prefer to let the rcu people fix it. > 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. It works exactly the same way. Interrupts started in parallel with an ID update will use either map. Interrupts started afterwards will use the new map. > > We can add a tracepoint so that we can detect it if this starts > happening a lot for some guest. > No point, guests don't update their APIC ID (or related) after booting. -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
