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