Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 20 Oct 2005 15:05:19 +0200
From:      "Poul-Henning Kamp" <phk@phk.freebsd.dk>
To:        Bruce Evans <bde@zeta.org.au>
Cc:        Scott Long <scottl@samsco.org>, src-committers@freebsd.org, Andrew Gallatin <gallatin@cs.duke.edu>, cvs-src@freebsd.org, cvs-all@freebsd.org, David Xu <davidxu@freebsd.org>
Subject:   Re: cvs commit: src/sys/amd64/amd64 cpu_switch.S machdep.c 
Message-ID:  <25362.1129813519@critter.freebsd.dk>
In-Reply-To: Your message of "Thu, 20 Oct 2005 22:55:23 %2B1000." <20051020215101.Y874@delplex.bde.org> 

next in thread | previous in thread | raw e-mail | index | archive | help
In message <20051020215101.Y874@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@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.



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?25362.1129813519>