Re: Follow-up on Linux-kernel code accessibility

[Paul E. McKenney]

On Mon, Dec 29, 2025 at 10:05:15PM +0000, Dr. David Alan Gilbert wrote:
> * Steven Rostedt (rostedt@xxxxxxxxxxx) wrote:
> 
> > There's nothing there that says "3" is needed. Why divide at all? Why not
> > just add 1?
> 
> Now while Paul obviously doesn't want to tell us, I decided I should
> do what someone who actually cared would do, and looked at the git history,
> To my surprise, I see I made a mistake - the three magic constants
> in this function were all added separately, and the two uses of '3'
> are not necessarily the same.
> 
> 8c7c4829a8 - from 2016 
>   rcu: Awaken grace-period kthread if too long since FQS
> 
>   says it's a crude hack but doesn't mention why it chose 3 in the commit
>   message; among other stuff it adds:
> 
> +                               WRITE_ONCE(rsp->jiffies_kick_kthreads,
> +                                          jiffies + 3 * j);
> 
> 9cf422a8 - from 2018
>   rcu: Accommodate zero jiffies_till_first_fqs and kthread kicking
> 
>   replaces that:
> -                                  jiffies + 3 * j);
> +                                  jiffies + (j ? 3 * j : 2));
> 
>   to stop using too much cpu and says 'at least two jiffies'
> 
> fb77dcc - from 2022
>   rcu: Decrease FQS scan wait time in case of callback overloading
> 
>   introduces the:
>   j = (j + 2) / 3;
> and commit message says:
>     This commit therefore divides the normal time between rescans by three,
>     rounding up.  Thus a small system running at HZ=1000 that is suffering
>     from callback overload will wait only one jiffy instead of the normal
>     three between rescans.
> 
> So that one does have a commit message explanation at least; although
> I'm not sure I know where the 'normal three' comes from - but I guess
> that's followable eventually.
> 
> But heck, this is making it hard to find them.

I do appreciate your digging in and looking in at least the git-history
direction!

							Thanx, Paul