review high-res-timers patches

From: Randy.Dunlap (
Date: Wed Feb 12 2003 - 18:15:05 EST

| By the way, is there any comparison of the two patches
| available? One of the things stopping Linus may be
| that we haven't come to a consensus as to which of
| the patches is "right".

Here's the current status of CGL review of them.



Geoff Gustafson, Julie Fleischer, and I have spent some time on high-res-timers review and testing. The initial goals were:

(a) requirements justification for CGL; (b) code review and feedback; and (c) conformance, functional, and performance/stress testing.

(a) Requirements

"Requirement: 6.4.1 Concurrent Timers Scaling Behavior and Report Description: OSDL CGL shall determine support for applications that require scaling of total count of system timers into the 1000s."

[This is not _that_ report.]

(b) Code review and feedback

I reviewed Jim Houston's "alternate" timers patch and sent comments on it to to and

Review of George Anzinger's high-res-timers patch is currently postponed indefinitely.

A few notable differences in the patches, mostly from a usability viewpoint instead of an implementation viewpoint:

. Jim's patch is not a CONFIG option but George's patch is. . Jim's patch works with TSC or PIT a timer source whereas George's patch uses TSC, PIT, or the ACPI timer (CONFIG-selectable).

(c) Code testing

Julie maintains a POSIX test suite at <>. There is also some verification/conformance code in the high-res-timers support patch at <>.

There are still some POSIX conformance issues with the original HRT patches, although some of these may be fixed in the most recent versions of the patches. The alternate patchset passes all POSIX conformance tests. See <> for test results.

I created a timerstress program to test 1000s of active timers. I ran it on Linux 2.5.59 with George's HRT patch, with profile=4 (in-kernel profiling) on a dual P4 1.7 GHz PC with 1 GB of RAM.

All stress tests were run for 60 seconds, with random initial timeout and interval per timer (initial timeout == interval). Currently all timers are relative in time, not absolute. The timerstress test uses one POSIX real-time signal and no other threads/processes, so this isn't a timer + threads test, just a timers/signals test.

As you can see in the following table, the high-res-timers code is not taking unusual amounts of processor time, although the system call overhead from the timer stress test program is high.

Timers Expirations/60 seconds Avg/second Syscall 'load' (profile) ============================================================================== 1000 2505 41.75 5.20 2000 4852 80.87 5.18 3000 7175 119.58 5.68 4000 9588 159.8 8.66 5000 12026 200.43 9.68 6000 14284 238.07 8.89 7000 16669 277.82 12.59 8000 19134 318.9 9.84 9000 21597 359.95 14.41 10000 24288 404.8 11.55 12000 28812 480.2 11.41 14000 33606 560.1 28.16 16000 38680 644.67 18.11

Stress testing of Jim's alternate HRT patch is currently on hold.

### - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to More majordomo info at Please read the FAQ at

This archive was generated by hypermail 2b29 : Sat Feb 15 2003 - 22:00:45 EST