Re: [discuss] Re: [RFC, patch] i386: vgetcpu(), take 2

[Andi Kleen <ak@suse.de>]

> It just does not sound like a right interface.  Why should an app be
> giving the last time value that it asked for the same information.  

First this information comes with a good-before date stamp
so it's natural. Otherwise the application will never pick
up when the scheduler decides to schedule it somewhere else,
which would be bad.

And that came from conversation with application developers.

A: We want something to get the current node
me: how fast does it need to be? 
B: we will cache it anyways.

Problem is that normally the application can't do a good job
at doing the cache because it doesn't have a fast way to 
do time stamping (gettimeofday would be too slow and it's
the fastest timer available short of having a second thread
that sleeps and updates a counter) 

But the vsyscall incidentially knows this because of it
sharing data with  vgettimeofday(), so it can
do the job for the application

> User 
> wants cpu, package and node numbers and those are the three parameters
> that should be there.  Besides if we are using lsl then the latency part
> of cpuid is already gone so no need to optimize this any more.
>
> Though this will be good interface to export jiffies ;-)

No - jiffies don't have a defined unit and might even go away
on a fully tickless kernel.

If we just exported jiffies you would get lots of HZ dependent
programs.

-Andi