hrtimer_start problem?

[Jim Houston]

Hi Thomas,

The logic in hrtimer_start() which controls the reprogram argument
to enqueue_hrtimer() looks broken to me.  I assume that intent is
to set the hardware timer only if the hrtimer is being enqueued on
a local base.

The existing test "base == new_base" will skip programming the timer
if it was moved from another cpu.  Normally switch_hrtimer_base() will
find that the timer is already on the local base or will move the timer
to the local base.  In both of these cases it seems necessary to
program the timer.  The case where the timer should not be programmed
is if switch_hrtimer_base() failed to move the timer and it is
still associated with a non-local base.

There are two failure mechanisms.  The common case fails to
set the hardware timer even though the timer has been moved 
to the local base.  This would cause the hrtimer's expiry to
be delayed until the time when the hardware timer was currently
programmed to expire.  In the case where timer could not be moved,
we program the local timer using a mishmash of information from
the local and remote bases.

I ran into this with a Concurrent kernel based on your
patch-2.6.18-hrt-dyntick2.  I have checked that the logic is
still the same in kernel.org.


Jim Houston - Concurrent Computer Corp.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/