Re: Per-Processor Data Page

Linus Torvalds (torvalds@transmeta.com)
Thu, 9 Dec 1999 13:40:16 -0800 (PST)


On 9 Dec 1999, Andi Kleen wrote:
>
> I've seen gettimeofday() often as a example here in this thread for magic
> user process mappings, and I think that is wrong. gettimeofday() nowadays
> uses the CPU internal cycle counter to get very accurate timings. You would
> never be able to implement a counter in some memory location as accurately
> as the CPU does. Reading it requires some internal knowledge though (e.g.
> the delta between the counters on SMP systems and thus the current CPU cpu),
> which are better left in a system call.

Note that I will NOT EVER accept a patch that exports kernel data
structures to user space this way. No way will I have something that says
"at magic address 0xffff002 can you find the current time". That is just
broken.

The _only_ thing I am considering exporting is CODE. That code can have
data information embedded into it, but I would not even consider something
that exports "xtime" per se. What I would consider is simply

- if you want to get the fastest "gettimeofday()", then use

static inline int gettimeofday(struct timeval *tv, struct timezone *tz)
{
asm("call 0xffff002"
:"=a" (error)
:"b" (tv), "c" (tz)
:"memory");
if (error)
errno = -error;
return error;
}

> For getpid alone it is not worth it IMHO (except if you want better lmbench
> numbers), and after that there are not many system calls left that only
> return simple values (you don't want to optimize uname, do you?)

Getpid() is not worth optimizing. The only reason _ever_ to optimize
getpid() is silly and bad benchmarks. Nobody uses it in real life.
Besides, getpid() doesn't work anyway, because it's not global. We only
want to do this if we can REALLY speed things up, and the only thing we
can REALLY speed up are global things where you really can set up things
once and get a noticeable win.

So "gettimeofday()" in contrast to getpid() can be _extremely_ time-
critical in real life. It's one of the most important routines for a lot
of X programming, for example.

Linus

-
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/