On Mon, 8 Sep 2008, Dâniel Fraga wrote: > On Mon, 8 Sep 2008 13:27:43 +0300 (EEST) > "Ilpo Järvinen" <ilpo.jarvinen@xxxxxxxxxxx> wrote: > > > It could well be possible, accept seems to call schedule_timeout if > > nothing is immediately available (but I don't know well enough what > > end up being hrtimer'ed when you enable them and what will not)... > > Anyway, how long did you test for that to confirm it? > > It has been five days since I disable high resolution timer and > have not got any problems anymore. > > > Does this explain the 2.6.24->2.6.25 change in behavior as well (ie., > > did they got enabled there)? > > Well, as far as I know, high res timer related, what changed > in 2.6.25 is the following: > > http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=8f4d37ec073c17e2d4aa8851df5837d798606d6f > > (although if I disable dynticks, the problem persists) > > Although in 2.6.24 we already had, for example the x86-32/64 > arch reunification and I don't know if it has anything to do with my > problem in 2.6.25... just some thoughts... I wrote that because the > problem doesn't happen in 32 bit machines, but only in x86_64... > > Of course I'm not saying for sure that the high res timer is > causing this. Maybe, as you said before, the problem is much more > complex and realy don't know what in fact uses high res timer. > > Anyway, I'll leave high res timer disabled for now until we > discover something new. ...I guess it would be possible to remove SCHED_FEAT_HRTICK from /proc/sys/kernel/sched_features then while keeping the hrtimers otherwise enabled to test this. It's possible that hrtimers just affect on how easy it is to trigger but at least it seems an useful lead until proven otherwise. -- i.
