Date: Fri, 14 Oct 2005 16:05:31 +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: <13600.1129298731@critter.freebsd.dk> In-Reply-To: Your message of "Fri, 14 Oct 2005 08:52:21 EDT." <17231.43525.446450.161986@grasshopper.cs.duke.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <17231.43525.446450.161986@grasshopper.cs.duke.edu>, Andrew Gallatin writes: > >Poul-Henning Kamp writes: > > The best compromise solution therefore is to change the scheduler > > to make decisions based on the TSC ticks (or equivalent on other > > archs) and at regular intervals figure out how fast the CPU ran in > > the last period and convert the TSC ticks accumulated to a time > > unit suitable for resource accounting. > > > > > > The bad solution is to try to do timekeeping based on hardware > > counters which are unsuitable for the purpose, the TSC being > > the primary suspect here, and we will not do that. > >I'll bet that nobody will want to touch the scheduler, so we'll >continue be stuck with inflated context switch times on SMP because we >use such an expensive time source. > >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. -- 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?13600.1129298731>