Re: powerpc64 head -r344018 stuck sleeping problems: th->th_scale * tc_delta(th) overflows unsigned 64 bits sometimes [patched failed]

On Sat, 2 Mar 2019, Poul-Henning Kamp wrote:

> --------
> In message <[email protected]>, Konstantin Belousov writes:
>
>> Using more than two timehands increases a chance of reader to try to
>> use outdated timehands.
>
> No, using only two timehands increase the chance that the reader tries
> to use the timehand which is being updated.

Then it sees the generation change and retries.  We fixed the ordering
of accesses to the generation count so that this is robust.  1 timehands
is always valid, so with 2 timehands there is no wait for the retry
except in the very unlikely event that the generation changes for the
new timehands too.  1 timehands would work too, but the retries would
have to wait while it is updated.

> As long as the reader does not use the timehand being updated, using
> a one or two generations old timehand is OK.

In old versions, there were races checking the generation count.  Having
multiple timehands made these races more unlikely to matter.

> The target-value for delta-t was "a few milliseconds" when I wrote
> timecounters, if somebody has changed that since, I hope they did
> their math first.

Tickless kernels complicate things.  It's surprising that tc_ticktock()
works so well with them.  Calls to hardclock() are not periodic, so
calls to tc_ticktock() are not periodic either.  It has to handle
coalesced and 1/hz ticks.  Too much coalescing would break it.  With
my normal hz = 100, cpu0:timer interrupts still occur at at least 100 Hz.
These presumably go to hardclock(), so the timing is satisfied.  With
hz = 1000, cpu0:timer interrupts only occur at at least 200 Hz.  This
is less than tc_ticktock() expects, but it still works.

Bruce
_______________________________________________
[email protected] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ppc
To unsubscribe, send any mail to "[email protected]"