Date: Fri, 14 Oct 2005 10:46:11 -0700 From: Matthew Reimer <mreimer@vpop.net> To: net@freebsd.org Subject: Re: Call for performance evaluation: net.isr.direct (fwd) Message-ID: <200510141046.11620.mreimer@vpop.net>
next in thread | raw e-mail | index | archive | help
Poul-Henning Kamp wrote: > 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. Would the hardware performance counters be suitable for that, at least on processors that have them? Matt
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200510141046.11620.mreimer>