Messages in this thread | | | Date | Wed, 28 Jul 1999 07:49:03 +0200 (CEST) | From | Robert de Vries <> | Subject | Re: 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/
| |