Date: Tue, 1 Nov 2005 05:00:37 +1100 From: Peter Jeremy <PeterJeremy@optushome.com.au> To: Poul-Henning Kamp <phk@phk.freebsd.dk> Cc: freebsd-current@freebsd.org, David Xu <davidxu@freebsd.org> Subject: Re: TSC instead of ACPI: powerd doesn't work anymore (to be expected?) Message-ID: <20051031180037.GA39882@cirb503493.alcatel.com.au> In-Reply-To: <81213.1130754398@critter.freebsd.dk> References: <4365EF7B.1020706@freebsd.org> <81213.1130754398@critter.freebsd.dk>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 2005-Oct-31 11:26:38 +0100, Poul-Henning Kamp wrote: >In message <4365EF7B.1020706@freebsd.org>, David Xu writes: >>We can introduce >>hrtime_t clock_gethrtime(clockid_t clock) to get hi-resolution time >>as the one seen in RTLinux, or gethrtime() as seen in Solaris (Daniel >>Eischen said?) ... >The open group specifically allow clock_gettime() to implement >more timescales, so what did those fools go and invent even more >library functions for ? gethrtime() dates back to SunOS 4.x and (AFAIK) predates TOG's work. ISTR it's not really a syscall but just reads the HR clock out of the magic page with the timer. I'd also support a move to make gettimeofday() a cheaper syscall that counts in 1/hz and require the use of clock_gettime() for accurate timestamps. This still leaves the issue of the scheduler - do we need an accurate (and expensive) record of how long a particular process executes? We can probably make the timestamps slightly cheaper to obtain since we only need to keep track of a time difference on a single CPU - there's no need for inter-CPU synchronisation (because a thread can't migrate from from CPU to CPU without the scheduler knowing). It probably doesn't even matter if the time intervals provided to the scheduler are inaccurate by a few percent or differ slightly between CPUs. -- Peter Jeremy
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20051031180037.GA39882>