Re: [PATCH] Use local APIC timer to drive kernel clocks

From: Poul-Henning Kamp <phk_at_phk.freebsd.dk>
Date: Sat, 15 Jan 2005 10:32:39 +0100
In message <20050115071606.GB53545_at_cirb503493.alcatel.com.au>, Peter Jeremy wri
tes:

>This would seem to negate the benefit of statclock.  If a process
>synchronises to hardclock, and statclock is derived from hardclock
>then the process will also be synchronised to statclock - and can
>therefore (at least partially) circumvent the scheduler's attempts
>to stop processes hogging the CPI.

It is actually far worse than this.

Back when hardclock() was new, the cpu would execute around 10000
instructions per tick, these days it will execute around 1000000
instructions per tick.  Realistically we should have a Hz of 1MHz
to maintain decent probabilities for scheduler and in particular
profiling.

Unfortunately, the time to service an interrupt has stayed close
to constant while cpus got three orders of magnitude faster (mostly
because the speed was gained by adding pipelines, caches etc) so
this is utterly impossible.

Results from statistical profiling is so close to meaningless these
days that we might as well just remove it.

statclock is a hard one, I think it is still cheaper than doing
comprehensive accounting (ie: actually timing when you move between
the three states) but I think the margins are getting smaller.  Real
computer architectures have hardware counters for that sort of stuff.

Poul-Henning

-- 
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 15 2005 - 08:32:42 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:38:26 UTC