hrtimer_start problem?

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.

Re: hrtimer_start problem?

[Thomas Gleixner]

On Mon, 2007-04-02 at 15:01 -0400, Jim Houston wrote:
> 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.

It's fixed with commit 935c631db827cc3a96df4dcc6fec374b994fdbd1

	tglx