[parisc-linux] Generic light-weight syscall.

[Carlos O'Donell]

> > We discussed this in the Black Thorn ... record what value you last
> > returned to the user and never return less than that.
> 
> Not very nice if the difference between CPUs is significant.  You could
> find yourself checking time on CPU A, doing some work, getting moved to
> CPU B, checking time, and finding you apparently did all that in 0ns.

Willy and myself talked about this, you just return 1ns in the case
where you know that _something_ must have taken _some_ amount of time
(e.g. the insns that make up fast gettimeofday) so you couldn't have done
it in zero time :)

I also just noticed (thanks to jejb) that cr16 is readable from
userspace since we leave PSW-S cleared. So the following works:

        unsigned long cr16;
        asm("mfctl %%cr16, %0" : "=r" (cr16) : );
        printf("cr16=%lu\n",cr16);

---
carlos@firin:~$ ./test_cr16_read 
cr16=3544734914
carlos@firin:~$ ./test_cr16_read 
cr16=4230470557
carlos@firin:~$ ./test_cr16_read 
cr16=2337868642
carlos@firin:~$ 
---

It overlaps pretty fast though. Userspace could do the translation and
hold on to a 'last_tick' value and then return a really small value if
we get scheduled onto a negatively-drifted CPU? Do all CPU's update cr16?

Willy, I just realized that the following trail of function calls
doesn't really work under smp:

glibc -> 
 gettimeofday -> 
  syscall + syscall table lookup -> 
   sys32_gettimeofday ->
    do_gettimeofday ->
     gettimeoffset ( returns 0 in smp)

With the comment I don't quite understand:
linux-2.4/arch/parisc/kernel/time.c
   /*
    * FIXME: This won't work on smp because jiffies are updated by cpu
    * 0.
    *    Once parisc-linux learns the cr16 difference between
    *    processors,
    *    this could be made to work.
    */

Does that mean that our time granularity drops drastically in the SMP
case? We loose usec! (2.4 and 2.5 kernels)

c.