Date: Fri, 14 Oct 2005 17:44:33 +0200 From: "Poul-Henning Kamp" <phk@phk.freebsd.dk> To: Andrew Gallatin <gallatin@cs.duke.edu> Cc: Garrett Wollman <wollman@csail.mit.edu>, net@FreeBSD.org Subject: Re: Call for performance evaluation: net.isr.direct (fwd) Message-ID: <31823.1129304673@critter.freebsd.dk> In-Reply-To: Your message of "Fri, 14 Oct 2005 10:54:17 EDT." <17231.50841.442047.622878@grasshopper.cs.duke.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <17231.50841.442047.622878@grasshopper.cs.duke.edu>, Andrew Gallatin writes: > > >What if somebody were to port the linux TSC syncing code, and use it > > >to decide whether or not set kern.timecounter.smp_tsc=1? Would you > > >object to that? > > > > Yes, I would object to that. > > > > Even to this day new CPU chips come out where TSC has flaws that > > prevent it from being used as timecounter, and we do not have (NDA) > > access to the data that would allow us to build a list of safe > > hardware. > >Bear in mind that I have no clue about timekeeping. I got into this >just because I noticed using a TSC timecounter reduces context switch >latency by 40% or more on all the SMP platforms I have access to: > >1.0GHz dual PIII : 50% reduction vs i8254 >3.06GHz 1 HTT P4 : 55% vs ACPI-safe, 70% vs i8254) >2.0GHz dual amd64: 43% vs ACPI-fast, 60% vs i8254) The solution is not faster but less reliable timekeeping, the solution is to move the scheduler(s) away from using time as an approximation of cpu cycles. >However, if the linux solution is not >correct, then somebody with timekeeping knowledge needs to get >involved. Is this you? The linux "solution" is not correct, and timekeeping knowledge I have, but the solution is in the scheduler where my clue is limited. >BTW, is an algorithm like Solaris' the "best compromise" you mention >above? Or is it just keeping the TSC in sync? They seem to maintain >a high resolution timer based on tsc, and keep it in sync every >second, and fixup drift on different cpus, and the TSC >being reset after suspend/resume. >http://cvs.opensolaris.org/source/xref/usr/src/uts/i86pc/os/timestamp.c Solaris don't change the tsc frequency by a factor 8 without giving the OS a chance to know about it. -- 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?31823.1129304673>