Re: [LEAPSECS] Introduction of long term scheduling

From: Poul-Henning Kamp <phk_at_phk.freebsd.dk>
Date: Sat, 06 Jan 2007 19:19:38 +0000

In message <20070106.093559.228973616.imp_at_bsdimp.com>, "M. Warner Losh" writes:
>In message: <BBA8EEA7-2D53-4A51-8F46-30D400AFFF98_at_semantic.org>
> Ashley Yakeley <ashley_at_SEMANTIC.ORG> writes:

>OSes usually deal with timestamps all the time for various things. To
>find out how much CPU to bill a process, to more mondane things.
>Having to do all these gymnastics is going to hurt performance. One
>might scoff at this statement, but research into performance problems
>and issues has found time and again timekeeping and timestamps to have
>a surprisingly large impact. So for the foreseeable future,
>timestamps in OSes will be a count of seconds and a fractional second
>part. That's not going to change anytime soon even with faster
>machines, more memory, etc. Too many transaction processing
>applications demand maximum speed.

I will agree with Warner here, but I will add the footnote that
since silicon pushers seem to be at a loss for how to gainfully
employ silicon these days, we are not particular insistent on any
particular aspect of the timestamps, apart from them being cheap
to get, add, subtract and compare.

If the silicon designers want to build in support for
        YYYYMMDDHHMMSS.mmmuuunnnppp
BCD encoded timestamps, as long as they provide us with cheap
instructions to carry out the above operations, we're happy.

I should caution any hopes however, by mentioning that at this
time I have yet to see any CPU design getting a binary counter
running at a predictable rate right in first try.

--
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk_at_FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
Received on Sat Jan 06 2007 - 11:31:58 PST

This archive was generated by hypermail 2.3.0 : Sat Sep 04 2010 - 09:44:55 PDT