KallistiOS icon indicating copy to clipboard operation
KallistiOS copied to clipboard

Scheduling Precision Upgrade

Open gyrovorbis opened this issue 1 year ago • 2 comments

FINALLY attempting to complete the remainder of the precision upgrades we an now enjoy from the new TMU driver all the way down to the scheduler level... WIP!

  • timer_spin_sleep is a macro that resolves to timer_spin_sleep_ms().
  • timer_spin_sleep_us() and timer_spin_sleep_ns() have been added.
  • timer_spin_sleep_xxx() no longer even directly consume a TMU unit. Instead, they simply spin in a loop comparing a time delta against timer_xx_gettime64() values.
  • Lots of Doxygen update/cleanup.

gyrovorbis avatar May 02 '24 00:05 gyrovorbis

I tend to disagree with the implementation and the claim that it "complete the remainder of the precision upgrades":

  • It does not address the elephant in the room, the fact that thd_sleep(1) will sleep for a minimum of 10 milliseconds;
  • timer_spin_sleep_ms() shouldn't really exist IMHO, and timer_spin_sleep() should just resolve to thd_sleep() instead.

pcercuei avatar May 02 '24 10:05 pcercuei

I tend to disagree with the implementation and the claim that it "complete the remainder of the precision upgrades":

  • It does not address the elephant in the room, the fact that thd_sleep(1) will sleep for a minimum of 10 milliseconds;
  • timer_spin_sleep_ms() shouldn't really exist IMHO, and timer_spin_sleep() should just resolve to thd_sleep() instead.
  1. Yeah, that's a fair point... I wasn't even fully aware of that fact when I first set out to start making these changes... but I guess the scheduler is what is updating genwait() with the delta time, NOT the other way around, so the best-case latency for a sleep is still going to be the remaining time before a the scheduler interrupt gets called... Basically the logic for the scheduler rescheduling itself should be the MIN between the scheduling interval or the next timeout from the genwait() queue...

  2. Oh... yeah... That wasn't on my radar, because I was worried that it would be considered an API break to map timer_spin_sleep() to an actual thread sleep, but now that I think about it, IIRC if you attempt to sleep in an interrupt it basically does a spin sleep anyway, so this should actually still work in all scenarios.... So maybe this should be how we implement that call...

gyrovorbis avatar May 02 '24 14:05 gyrovorbis