review high-res-timers patches

[Randy.Dunlap]

| 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.
--
~Randy

=====================================================================

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 [e-mail] and
[e-mail].

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 <http://posixtest.sourceforge.net/>.
There is also some verification/conformance code in the high-res-timers
support patch at <http://sourceforge.net/projects/high-res-timers/>.

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 <http://posixtest.sourceforge.net/testpass.html> 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.

###