cvs commit: src/sys/amd64/amd64 cpu_switch.S machdep.c

[Poul-Henning Kamp]

In message <20051020215101.Y874 at delplex.bde.org>, Bruce Evans writes:
>On Thu, 20 Oct 2005, Poul-Henning Kamp wrote:

>This point is for all the functions.  A timestamp taken by 1 thread
>might not be used until after many timestamps are taken and used by
>other threads.  Naive comparison of these timestamps would then give
>apparent incoherencies.

Ahh, but now we're into the "programmer doesn't understand concurrency"
territory, that has little to do with our timekeeping functions.

>On hub a few hours ago, csw was a transient 100-500 and the
>average since boot time was 1010.

The average since boot should not be optimized for, since we don't
really care what the machine does (or doesn't) when we are not
offering any workload to it.

>So unavoidable context switches can happen
>a lot on busy machines and the scheduler can't/shouldn't affect their
>count except possibly to reduce it a bit.  Given that they happen a lot
>on some systems, they should be as efficient as possible.  I think the
>timecounter part of their inefficiency is not very important except in
>the usual case of a slow timecounter.  Losses from busted caches may
>dominate.

I would tend to agree with you there, but any sensible optimization
should be done.

>> It's so nice to have you back in action Bruce :-)
>
>I don't plan to stay very active.

Too bad, your considered opinion, even though we often disagree,
is one of the things I really enjoy around here: it forces me to
think harder.

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