[RFC][patch] time applet execution speed

[Bernhard Fischer]

On Sun, Sep 25, 2005 at 05:14:22PM -0500, Rob Landley wrote:
>On Sunday 25 September 2005 15:49, Bernhard Fischer wrote:
>> On Sat, Sep 24, 2005 at 01:33:18PM -0500, Rob Landley wrote:
>> >Does rdtsc work happily across scheduler invocations?
>>
>> I don't see why it shouldn't. rdtsc and the PPC variant are reading
>> a CPU built-in timer source. It will of course wrap every now and

>Actually, what I meant was more along the lines of if an interrupt comes in, 
>that time is credited to this process, and if we're scheduled away and 
>something else runs for 1/10 of a second is _that_ credited to this process, 
>and isn't it even theoretically possible that the other process could reset 
>the timer?

The TSC is set to 0 if it wraps (on a 3GHz CPU approximately every 190
years) or if the given CPU is reset. The CPU reset is imho not a
concern as you have to set the CPU offline before you replace it
anyways.

rdtsc();schedule();rdtsc(); gives the total elapsed time.

This implies that on a loaded system, the measured time applet takes to
run from start to it's end will be greater than on an idle system. It's
just a wallclock timer, which is a bit more accurate (253668511.pdf,
IA-32 Architecture Software Developer's Manual Vol.3, Sect. 15.8).

I do not know how many percent of the machines running busybox support
PMC (performance monitor counters, section 15.10.2 in abovementioned
doc).
>
>Or is the timer value a register that gets saved in our register profile when 
>we schedule?  (In which case migrating from CPU to CPU shouldn't be too bad 
>anyway.)

It's a CPU-local, monotonic counter and AFAIK is not saved in the flags.