Hello! Please find the next improved version of call_rcu_lazy() attached. The main difference between the previous versions is that: - In v2 rcu_barrier is fixed to not hang (I found this to be due to a missing GP thread wakeup), now I am limiting this wake up only to rcu_barrier() as requested by Paul. - Fixed checkpatch and build robot issues. - Some more changes to 'lazy' parameter passing and consolidation of segcblist functions. - more testing via rcutorture and rcuscale. Note that these tests were run on v2 patches, I am expecting similar power improvements however I've not yet tested power. Following are power savings we saw on top of RCU_NOCB_CPU on an Intel platform in v2. The observation is that due to a 'trickle down' effect of RCU callbacks, the system is very lightly loaded but constantly running few RCU callbacks very often. This confuses the power management hardware that the system is active, when it is in fact idle. For example, when ChromeOS screen is off and user is not doing anything on the system, we can see big power savings. Before: Pk%pc10 = 72.13 PkgWatt = 0.58 CorWatt = 0.04 After: Pk%pc10 = 81.28 PkgWatt = 0.41 CorWatt = 0.03 Further, when ChromeOS screen is ON but system is idle or lightly loaded, we can see that the display pipeline is constantly doing RCU callback queuing due to open/close of file descriptors associated with graphics buffers. This is attributed to the file_free_rcu() path which this patch series also touches. On memory pressure, timeout or queue growing too big, we initiate a flush of of the bypass lists holding the lazy CBs. Similar results can be achieved by increasing jiffies_till_first_fqs, however that also has the effect of slowing down RCU. Especially I saw huge slow down of function graph tracer when increasing that. That may be possible to fix via rcu_expedited=1 boot parameter, however call_rcu_lazy() provides another option over slowing down ALL call_rcu() globally. Further using jiffies_till_first_fqs approach will still cause a wake up of the main RCU GP kthread, with this work we delay even those wakeups. One drawback of this series is, if another frequent RCU callback creeps up in the future, that's not lazy, then that will again hurt the power. However, I believe identifying and fixing those is a more reasonable approach than slowing RCU down for the whole system. Disclaimer: I have intentionally not CC'd other subsystem maintainers (like net, fs) to keep noise low and will CC them in the future after 1 or 2 rounds of review and agreements. Joel Fernandes (Google) (4): rcu: Introduce call_rcu_lazy() API implementation rcuscale: Add laziness and kfree tests fs: Move call_rcu() to call_rcu_lazy() in some paths rcutorture: Add test code for call_rcu_lazy() Vineeth Pillai (1): rcu: shrinker for lazy rcu fs/dcache.c | 4 +- fs/eventpoll.c | 2 +- fs/file_table.c | 2 +- fs/inode.c | 2 +- include/linux/rcu_segcblist.h | 1 + include/linux/rcupdate.h | 6 + kernel/rcu/Kconfig | 8 + kernel/rcu/rcu.h | 12 + kernel/rcu/rcu_segcblist.c | 15 +- kernel/rcu/rcu_segcblist.h | 20 +- kernel/rcu/rcuscale.c | 74 +++++- kernel/rcu/rcutorture.c | 60 ++++- kernel/rcu/tree.c | 132 ++++++---- kernel/rcu/tree.h | 10 +- kernel/rcu/tree_nocb.h | 239 ++++++++++++++---- .../selftests/rcutorture/configs/rcu/TREE11 | 18 ++ .../rcutorture/configs/rcu/TREE11.boot | 8 + 17 files changed, 508 insertions(+), 105 deletions(-) create mode 100644 tools/testing/selftests/rcutorture/configs/rcu/TREE11 create mode 100644 tools/testing/selftests/rcutorture/configs/rcu/TREE11.boot -- 2.37.0.144.g8ac04bfd2-goog
