Pierangelo Masarati wrote: > Philippe Gerum wrote: > >>>> Ok, you were talking about the _previous_ implementation, right? >>> Yes. It's been running for a few hours today, so your fix seems to be >>> fine; in any case, the tests will run overnight, and I'll let you know >>> tomorrow. I believe this issue could not be easily pointed out by just >>> a simple latency check. >>> >> Agreed, we need to create a load that makes races on seqlocks more likely, >> and >> ideally with lots of readers delaying a single writer. > > The testing of your fix ran overnight without problems, so we'd consider > it fine.
Ok, thanks. Will issue -03 asap. Another possible fix to preserve linux timings is to use > local_irq_disable_hw() after halt. It seems to create no significant > latency. > The only way to fully preserve the timings would involve running sched_clock_idle_wakeup_event() with hw interrupts off, which grabs a spinlock on the current runqueue; I'm worried about latencies introduced by sporadic contention on that lock due to task migrations. OTOH, the scheduler tick handler implements a counter-measure against underflows of the per-runqueue clocks, so even if the RTOS preempts often or for a long time the idling code, it should resync reasonably well. Hopefully. -- Philippe. _______________________________________________ Adeos-main mailing list [email protected] https://mail.gna.org/listinfo/adeos-main
