Hello, During studying some synchronize_rcu() latencies, I found that the jiffies_till_first_fqs value passed to the timer tick subsystem does is always off by one. This is natural due to calc_index() rounding up.
For example, jiffies_till_first_fqs=3 means the "Jiffies till first FQS" delay is actually 4ms. And same for the next FQS. In fact, in testing it shows it can never ever be 3ms for HZ=1000. And in rare cases, it will go to 5ms probably due to interrupts. Considering this, I think it is better to reduce the jiffies_till_first_fqs by 1 before passing it to the wait APIs. But before I wanted to send a patch, I wanted to get everyone's thoughts. Considering this the RFC. The other place I found this was when call_rcu_hurry() is called, but the GP thread takes a tick to wake up, but this isn't related to the timer per-se, it is just that we don't want to wake the GP thread too often. So we just wait for the next tick to notice callbacks before doing a wakeup. Heh, and this means synchronize_rcu() latencies will multiply when HZ < 1000. I wonder if this is also what caused Uladzislau to investigate it for mobile devices. - Joel
