|| ||Nishanth Aravamudan <email@example.com>|
|| ||john stultz <firstname.lastname@example.org>|
|| ||[RFC][PATCH 0/4] new timeofday-based soft-timer subsystem|
|| ||Tue, 17 May 2005 16:33:00 -0700|
|| ||lkml <email@example.com>,
Tim Schmielau <firstname.lastname@example.org>,
George Anzinger <email@example.com>,
Ulrich Windl <firstname.lastname@example.org>,
Christoph Lameter <email@example.com>,
Dominik Brodowski <firstname.lastname@example.org>,
David Mosberger <email@example.com>, Andi Kleen <firstname.lastname@example.org>,
keith maanthey <email@example.com>,
Chris McDermott <firstname.lastname@example.org>,
Max Asbock <email@example.com>, firstname.lastname@example.org,
Darren Hart <email@example.com>,
"Darrick J. Wong" <firstname.lastname@example.org>,
Anton Blanchard <email@example.com>, firstname.lastname@example.org,
On 13.05.2005 [17:16:35 -0700], john stultz wrote:
> This patch implements the architecture independent portion of the new
> time of day subsystem. For a brief description on the rework, see here:
> http://lwn.net/Articles/120850/ (Many thanks to the LWN team for that
> easy to understand writeup!)
> I intend this to be the last RFC release and to submit this patch to
> Andrew for for testing near the end of this month. So please, if you
> have any complaints, suggestions, or blocking issues, let me know.
I have been working closely with John to re-work the soft-timer subsytem
to use the new timeofday() subsystem. The following patches attempts to
begin this process. I would greatly appreciate any comments.
Some design points:
1) The patch is small but does a lot.
a) Renames timer_jiffies to last_timer_time (now that we are not
b) Converts the soft-timer time-vector's/bucket's entries to
timerinterval (a new unit) width, instead of jiffy width.
c) Defines timerintervals to be the current time as reported by the new
timeofday-subsystem shifted down by TIMERINTERVAL_BITS bits.
Thus, various pseudo-'human time' units can be emulated.
d) Uses do_monotonic_clock() (converted to timerintervals) as the basis
for addition and expiration of timers instead of jiffies.
e) Adds some new helper functions for dealing with nanosecond values.
2) The patch depends on John's timeofday core rework. For arches that
will not have the new timeofday (or for which the rework is still in
progress), I can emulate the existing system with a separate patch (Such
a possible patch will follow). The goal of this patch, though, is just
to show how easy the new system can be implemented and the benefits. It
has been tested on x86 and x86_64 archs; there may be some issues with
ppc and ppc64 which I am working on resolving.
3) The reason for the re-work? Many people complain about all of the
adding of 1 jiffy here or there to fix bugs. This new systems is
fundamentally human-time oriented and deals with those issues correctly
and, more importantly, sanely :)
The code is reasonably well commented, but does expect readers to
understand the current soft-timer subsystem.
This is still an early working of this patch, so I expect criticism, and
am happy to make changes.
I will try to get some current benchmark differentials posted tomorrow.
The previous patch I released showed little difference between mainline,
John's timeofday rework and my soft-timer rework in kernbench.
1/4: A small interdiff between John's current stack and what is
necessary for my patch to work. Moves timeofday.h architecture-specific
code to asm/timeofday.h. This is necessary for my patch.
2/4: Converts the soft-timer subsystem to use timerinterval as the units
of addition and expiration.
3/4: Converts, as an example, sys_nanosleep() to use the new interfaces
provided by patch 2. For instance, you (albeit somewhat rarely -- maybe
once out of every 100,000 requests) may get only 10 usecs of actual
sleep (instead of 2+ msecs no matter what).
4/4: Enables non-NEWTOD archs to use the same interfaces, with some
performance penalty (am working on a better alternative, this is just
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to email@example.com
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/