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. -- 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
