mirror of
https://github.com/BobTheBlinker/android_kernel_motorola_sm6375.git
synced 2026-10-22 04:29:04 -04:00
| Filename | Latest commit message | Latest commit date |
|---|---|---|
77e9752ce6
It is possible that the rcuperf kernel test runs concurrently with init starting up. During this time, the system is running all grace periods as expedited. However, rcuperf can also be run for normal GP tests. Right now, it depends on a holdoff time before starting the test to ensure grace periods start later. This works fine with the default holdoff time however it is not robust in situations where init takes greater than the holdoff time to finish running. Or, as in my case: I modified the rcuperf test locally to also run a thread that did preempt disable/enable in a loop. This had the effect of slowing down init. The end result was that the "batches:" counter in rcuperf was 0 causing a division by 0 error in the results. This counter was 0 because only expedited GPs seem to happen, not normal ones which led to the rcu_state.gp_seq counter remaining constant across grace periods which unexpectedly happen to be expedited. The system was running expedited RCU all the time because rcu_unexpedited_gp() would not have run yet from init. In other words, the test would concurrently with init booting in expedited GP mode. To fix this properly, this commit waits until system_state is set to SYSTEM_RUNNING before starting the test. This change is made just before kernel_init() invokes rcu_end_inkernel_boot(), and this latter is what turns off boot-time expediting of RCU grace periods. Signed-off-by: Joel Fernandes (Google) <joel@joelfernandes.org> Signed-off-by: Paul E. McKenney <paulmck@linux.ibm.com> |
||
| .. | ||
| Kconfig | ||
| Kconfig.debug | ||
| Makefile | ||
| rcu.h | ||
| rcu_segcblist.c | ||
| rcu_segcblist.h | ||
| rcuperf.c | ||
| rcutorture.c | ||
| srcutiny.c | ||
| srcutree.c | ||
| sync.c | ||
| tiny.c | ||
| tree.c | ||
| tree.h | ||
| tree_exp.h | ||
| tree_plugin.h | ||
| tree_stall.h | ||
| update.c | ||