On Fri, May 13, 2022 at 04:55:34PM +0200, Uladzislau Rezki wrote: > > On Thu, May 12, 2022 at 03:04:38AM +0000, Joel Fernandes (Google) wrote: > > > Signed-off-by: Joel Fernandes (Google) <joel@xxxxxxxxxxxxxxxxx> > > > > Again, given that kfree_rcu() is doing its own laziness, is this really > > helping? If so, would it instead make sense to adjust the kfree_rcu() > > timeouts? > > > IMHO, this patch does not help much. Like Paul has mentioned we use > batching anyway. I think that depends on the value of KFREE_DRAIN_JIFFIES. It it set to 20ms in the code. The batching with call_rcu_lazy() is set to 10k jiffies which is longer which is at least 10 seconds on a 1000HZ system. Before I added this patch, I was seeing more frequent queue_rcu_work() calls which were starting grace periods. I am not sure though how much was the power saving by eliminating queue_rcu_work() , I just wanted to make it go away. Maybe, instead of this patch, can we make KFREE_DRAIN_JIFFIES a tunable or boot parameter so systems can set it appropriately? Or we can increase the default kfree_rcu() drain time considering that we do have a shrinker in case reclaim needs to happen. Thoughts? thanks, - Joel
