IRC channel logs

<damo22>youpi: how sure are we that +1 is needed on interval? when you add 1 tick unconditionally to t_time it defeats the speedup

<damo22>because every timeout gets an extra tick

<youpi>yes, I'm sure, some userland tests fail otherwise because nanosleep() sleeps not enough

<youpi>if it defeats the speedup, it means that the optimization was not actually that worth it, it's just timeouts which come in the way

<youpi>I'm not that surprised, to be honest: did you benchmark how many timeouts we had at the same time?

<youpi>I'm not saying the optimization is not worth it in general: with diskfs servers that have a lot of server threads which are all blocked on their own msg_timeout() call, there will be a lot of timeouts at the same time ; just not during boot

<damo22>okay

<damo22>i looked at the timeoutwheel and found there were not many entries at boot

<damo22>but the existing timeouts get set and reset

<damo22>i think this optimisation is good for when there are many threads

<damo22>the nextsoftcheck global solves the race condition we used to have with softclock and reset_timeout i think

<damo22>hmm maybe the timer calibration is off because we add a tick

<damo22>no that breaks it

<damo22>all good

IRC channel logs

2025-12-09.log