Date: Sat, 19 Apr 2008 13:02:22 +0000 From: "Poul-Henning Kamp" <phk@phk.freebsd.dk> To: "Daniel O'Connor" <doconnor@gsoft.com.au> Cc: gnn@freebsd.org, freebsd-current@freebsd.org, Julian Elischer <julian@elischer.org>, Andrew Gallatin <gallatin@cs.duke.edu> Subject: Re: TSC Timecounter and multi-core/SMP Message-ID: <60925.1208610142@critter.freebsd.dk> In-Reply-To: Your message of "Fri, 18 Apr 2008 12:35:23 %2B0930." <200804181235.29530.doconnor@gsoft.com.au>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <200804181235.29530.doconnor@gsoft.com.au>, "Daniel O'Connor" writes : >> You'd think that an invariant sync'd clock (fast to read) [...] > >Probably because it's very very difficult to get right :) Actually, I think people miss a number of points here. One is that timekeeping, scheduling and benchmarking has different needs. Timekeeping: By definition needs to be system global, and preferably cheap. Rates above 100 MHz are pointless, because of the nature of the sort of bus-structures we have these days. A good 32 bit counter which can be read atomically, running at > 10 MHz is perfect for this purpose. The ACPI timer is usually pretty perfect for this, apart from the cost of reading it, which is incredibly high. The ACPI-timer should be distributed to all cpu sockets to speed up access, and a hardware reset line, either shared with other purposes or a dedicated signal, should be used to synchronize them. Scheduling Can, and should, be per core, and needs deadline interrupts. Access should be very cheap. Resolution of approx 1µs is usually overkill due to the cost of context switch times. HPET gets this wrong in a number of ways. Benchmarking Only needs to be per CPU, needs to be high resolution which makes it almost impossible to keep them perfectly in sync. If not in sync, they are very hard to use without kernel support unless threads a locked to CPU for measurement. TSC has too unpredictable properties to be used without a lot of chip-type conditional code. -- 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?60925.1208610142>