lkml.org 
[lkml]   [1999]   [Jul]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: PATCH: POSIX 1003.1b timer minor fixes
On 27 Jul 1999, Ulrich Drepper wrote:

> Jakub Jelinek <jj@sunsite.ms.mff.cuni.cz> writes:
>
> > On the other side I wonder why are sys_clock_* in the kernel unless higher
> > than microsecond resolution is implemented. It seems to me like they really
> > don't do any job which could not be done in glibc, and do
> > not give even any performance advantages over it.
>
> No, this would be worthless. These are realtime extensions which are
> deisgned to have high accuracy and fast response times. With a
> userlevel implementation doing some multiplexing based on whatever
> timer would not help at all.

I disagree, because the system call overhead takes more time than the
execution of a switch statement.
Let me illustrate with a small example of how I see the implementation in
the C library of clock_gettime().
Reading the i386 TSC probably takes less time than a system call. Or am I
dead wrong here, and is Linux way better than I thought?

Robert


static int tsc_gettime(struct timespec *current_time)
{
static int once = 1;
long long counter;

if (once) {
/* do setup of various stuff */
/* like getting the resolution of the TSC */
/* or mapping register to user space */

once = 0;
}
counter = rdtsc();

TSC_TO_TIMESPEC(counter, current_time);

return 0;
}


int clock_gettime(clockid_t which_clock, struct timespec *current_time)
{
switch (which_clock) {
case CLOCK_TSC:
return tsc_gettime(current_time);
default:
return sys_clock_gettime(which_clock,
current_time);
}
}



-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:53    [W:0.406 / U:0.056 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site