Hi Gilles, Gilles Carry wrote:
Le 19 août 08 à 16:10, Gregory Haskins a écrit :Hi Gilles, Gilles Carry wrote:This patch makes hrtimers initialized with hrtimer_init_sleeper to use another mode and then not be stuck in waitqueues when hrtimer_interrupt is very busy.Not sure if this is related, but I just posted a patch to fix a condition where hrtimer_interrupt could get artificially busy for *very* long periods of time (I observed 500ms).http://article.gmane.org/gmane.linux.rt.user/3357This bug was specific to 26-rt1. Did you investigate the cause of the busy hrtimer_interrupt? If not, its possible that your issue would be indirectly fixed now that the HRT subsystem doesn't spike-out like that. Or do you believe these are orthogonal issues and we should still protect against non-pathological cases of hrtimer_interrupt running hot?Hello Greg,The cause of busy hrtimer interrupt is the test that stresses the system. Many timers expire and are treated in a single interrupt run.Anyway looking at __run_hrtimer we can see: spin_unlock (&cpu_base->lock); restart = fn(timer); spin_lock(&cpu_base->lock); I guess It is the point where awaken threads might migrate to another cpu and reach hrtimer_cancel *before* __run_hrtimer has changed the timer state. (at the bottom of the function) This is why a new state machine is needed.
It sounds reasonable that both fixes are needed, then. Thanks. -Greg
Regards, Gilles.Regards, -Greg
Attachment:
signature.asc
Description: OpenPGP digital signature
