Re: Follow-up on Linux-kernel code accessibility
From: Dr. David Alan Gilbert
Date: Mon Dec 29 2025 - 17:05:31 EST
* 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.
Dave
--
-----Open up your eyes, open up your mind, open up your code -------
/ Dr. David Alan Gilbert | Running GNU/Linux | Happy \
\ dave @ treblig.org | | In Hex /
\ _________________________|_____ http://www.treblig.org |_______/