Commit da65f29
timers: Fix nextevt calculation when no timers are pending
When no timer is queued into an empty timer base, the next_expiry will not
be updated. It was originally calculated as
base->clk + NEXT_TIMER_MAX_DELTA
When the timer base stays empty long enough (> NEXT_TIMER_MAX_DELTA), the
next_expiry value of the empty base suggests that there is a timer pending
soon. This might be more a kind of a theoretical problem, but the fix
doesn't hurt.
Use only base->next_expiry value as nextevt when timers are
pending. Otherwise nextevt will be jiffies + NEXT_TIMER_MAX_DELTA. As all
information is in place, update base->next_expiry value of the empty timer
base as well.
Signed-off-by: Anna-Maria Behnsen <[email protected]>
Signed-off-by: Thomas Gleixner <[email protected]>
Reviewed-by: Frederic Weisbecker <[email protected]>
Link: https://lore.kernel.org/r/[email protected]1 parent bb8caad commit da65f29
1 file changed
+11
-2
lines changed| Original file line number | Diff line number | Diff line change | |
|---|---|---|---|
| |||
1922 | 1922 | | |
1923 | 1923 | | |
1924 | 1924 | | |
| 1925 | + | |
1925 | 1926 | | |
1926 | | - | |
1927 | 1927 | | |
1928 | 1928 | | |
1929 | 1929 | | |
| |||
1936 | 1936 | | |
1937 | 1937 | | |
1938 | 1938 | | |
1939 | | - | |
1940 | 1939 | | |
1941 | 1940 | | |
1942 | 1941 | | |
| |||
1945 | 1944 | | |
1946 | 1945 | | |
1947 | 1946 | | |
| 1947 | + | |
| 1948 | + | |
1948 | 1949 | | |
1949 | 1950 | | |
1950 | 1951 | | |
1951 | 1952 | | |
| 1953 | + | |
| 1954 | + | |
| 1955 | + | |
| 1956 | + | |
| 1957 | + | |
| 1958 | + | |
| 1959 | + | |
| 1960 | + | |
1952 | 1961 | | |
1953 | 1962 | | |
1954 | 1963 | | |
| |||
0 commit comments