Re: Tesing of / bugs in new timerfd API

On Thu, 13 Dec 2007, Michael Kerrisk wrote:

Davide, Andrew,

I applied Davide's v3 patchset (sent into LKML on 25 Nov) against
2.4.24-rc3, and did various tests (all on x86). Several tests
were done using the program at the foot of this mail. Various others
were done by cobbling together bits of code that I haven't included
here.

Thanks for such a thorough test Michael.



Tested: after setting a CLOCK_REALTIME timer with the
TFD_TIMER_ABSTIME flag to expire at some time in the past with
a non-zero interval (e.g., setting 100 seconds in the past, with
a 5 second interval), read() from the file descriptor returns
the correct number of expirations (e.g., 20).

This seems a reasonable thing to do, I suppose. However, while
playing around to test this, I found what looks like a bug (see
below).

BUG 1:
However, this test exposed what looks like a bug: if I set a
CLOCK_REALTIME clock to expire in the past, with a very small
interval, then the maximum number of expirations that can be
returned via read seems to be limited to 32 bits, even though
we have a 64-bit value for returning this information.
I haven't checked the kernel source to determine where this
bug is.

Yes, true. Right now hrtimer_forward() (that we use to get the "missed"
ticks) returns an unsigned long, that on 32 bit is (duh!) 32 bit :)
But hrtimer_forward() has all in place to just return an u64. So, Thomas,
would it be OK to have hrtimer_forward() (and the new hrtimer_forward_now())
to return a u64?




BUG 2:
The last sentence does not match the implementation.
(Nor is it consistent with the behavior of POSIX timers.
And I *think* things did work correctly in the original
timerfd() implementation, but I have not gone back to check.)

Suppose that we set an absolute timer to expire 100 seconds
in the future. Then according to this sentence of the man
page then each subsequent call to timerfd_gettime() should
retrun an itimerspec structure whose it_value steadily
decreases from 100 to 0 (when the timer expires). (This
is the behavior in the analogous situation with POSIX timers
and with setitimer()/getitimer().)

However, the implementation of timerfd_gettime() always
returns the "time when the timer would next expire", and
this value depends on whether TFD_TIMER_ABSTIME was specified
when setting the timer.

This is been like that from the beginning of the new API. So no, the
previous was behaving exactly the same WRT this feature.
Is this something really needed?



- Davide


--
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/

Relevant Pages

  • Re: ACPI PM-Timer on K6-3 SiS5591: Houston...
    ... this isn't the bug which is handled by the read-three-times-workaround. ... that handels the following PIIX4 errata: ... The power management timer may return improper results when read. ... Although the timer value settles properly after incrementing, ...
    (Linux-Kernel)
  • [PATCH 11/13] hrtimer: turn hrtimers into range timers
    ... Subject: hrtimer: turn hrtimers into range timers ... this patch turns hrtimers into range timers; they have 2 expire points ... expire point, the kernel now has the freedom to fire this timer at this point, ... the current task state has been set ). ...
    (Linux-Kernel)
  • RE: Timers not fireing System.Windows.Forms.Timer and System.Timer
    ... So It does appear to be a bug with AutoReset set True - I think it also ... > To test the bug and solve it, just add code at the begin of the Elapse event ... > found that exact time where your timer would stop firing. ... > AutoReset property to False the Enabled property should be False every time ...
    (microsoft.public.dotnet.framework.windowsforms)
  • Re: Help with the high res timers
    ... >> multiple bucket entries would be expired. ... For a HR timer, we need to know ... > HR timer code to take care of the nanosecond remainder. ... > timer for jiffie X will expire prior to a high res timer for jiffie X + Y ...
    (Linux-Kernel)
  • [patch] hrtimers debug patch
    ... I don't know how to reproduce this bug on 2.6.21-rc4. ... So to move this issue forward, i've written a hrtimers debug patch ... #ifdef CONFIG_HIGH_RES_TIMERS ... High resolution timer enabled? ...
    (Linux-Kernel)