Re: Fwd: do_gettimeofday vs. rdtsc in the scheduler

Re: Fwd: do_gettimeofday vs. rdtsc in the scheduler

[john stultz]

>  I'm writing a patch for the scheduler that allows normal processes to run 
>  occasionally even though real-time processes completely dominate the CPU. 
> In 
>  order to do this the way I want to for a specific real-time application, I 
>  need to keep track of the times that the schedule(void) function gets 
> called. 
>  This time is then used to calculate the time difference between when a 
> normal 
>  process was run last and the current time. I was trying to avoid 
>  do_gettimeofday because of the overhead, but now I'm wondering if rdtsc on 
> an 
>  SMP machine may mess up my readings because the TSC from two different 
>  processors may be read. Am I right in assuming this? Secondly, any good 
>  suggestions on how to proceed with my patch? 

Tread with caution. Some NUMA boxes do not have synced TSC, so on those
systems your code won't work. Additionally, you code would need to take
other technologies like speedstep into account as well  Alternatively,
you might want to try using get_cycles, or some other semi-abstracted
interface, so alternative time sources could be used in the future
without having to re-write your code. I'm working on somewhat
abstracting out time sources with my timer-changes patch, so take a peek
at it and let me know if you have any suggestions. 

thanks
-john

Re: do_gettimeofday vs. rdtsc in the scheduler

[David S. Miller]

   From: john stultz <johnstul@us.ibm.com>
   Date: 17 Sep 2002 13:29:18 -0700
   
   Some NUMA boxes do not have synced TSC, so on those systems your
   code won't work.

It would have been really nice if x86 had specified a "system tick"
register that incremented based upon the system bus cycles and thus
were immune the processor rates.

I foresee lots of patches coming which basically are "how does this
x86 system provide a stable synchronized tick source".

Re: do_gettimeofday vs. rdtsc in the scheduler

[David S. Miller]

   From: john stultz <johnstul@us.ibm.com>
   Date: 17 Sep 2002 13:57:13 -0700

   On Tue, 2002-09-17 at 13:39, David S. Miller wrote:
   > It would have been really nice if x86 had specified a "system tick"
   > register that incremented based upon the system bus cycles and thus
   > were immune the processor rates.
   
   Some systems do, if I'm understanding you properly. Summit based boxes
   have an on-chipset performance counter that runs at 100Mhz. My
   cyclone-timer patch uses this as a gettimeofday/__delay time source in
   the 2.4 kernel. Additionally George Anzinger has patches that allow the
   ACPI PM timer to be used as well. Intel's HPET should also provide
   another time source.

If any of these need to go beyond the cpu to get the tick value,
they are misimplemented.

The cpu gets the system bus tick input at it's bus pins, therefore
it can implement the system tick register locally obviating the need
to go to a south bridge or memory controller or whatever else external
to the cpu to get at the value.

Re: do_gettimeofday vs. rdtsc in the scheduler

[john stultz]

On Tue, 2002-09-17 at 13:39, David S. Miller wrote:
>    From: john stultz <johnstul@us.ibm.com>
>    Date: 17 Sep 2002 13:29:18 -0700
>    
>    Some NUMA boxes do not have synced TSC, so on those systems your
>    code won't work.
> 
> It would have been really nice if x86 had specified a "system tick"
> register that incremented based upon the system bus cycles and thus
> were immune the processor rates.

Some systems do, if I'm understanding you properly. Summit based boxes
have an on-chipset performance counter that runs at 100Mhz. My
cyclone-timer patch uses this as a gettimeofday/__delay time source in
the 2.4 kernel. Additionally George Anzinger has patches that allow the
ACPI PM timer to be used as well. Intel's HPET should also provide
another time source.
 
> I foresee lots of patches coming which basically are "how does this
> x86 system provide a stable synchronized tick source".

True, but hopefully my timer-changes patch will allow for better
abstraction around these varied time sources, so one won't really need
to know how all of these different sources work. 

thanks
-john