Re: [Patch 5/6] statistics infrastructure

[Martin Peschke <mp3@de.ibm.com>]

Andrew Morton wrote:
> Martin Peschke <mp3@de.ibm.com> wrote:
>> +static int statistic_alloc(struct statistic *stat,
>> +			   struct statistic_info *info)
>> +{
>> +	int cpu;
>> +	stat->age = sched_clock();
> 
> argh.  Didn't we end up finding a way to avoid this?
> 
> At the least, we should have statistics_clock(), or nsec_clock(), or
> something which is decoupled from this low-level scheduler-internal thing,
> and which architectures can implement (vis attribute-weak) if they have a
> preferred/better/more-accurate alternative.

I use clocks for two purposes. Both have used sched_clock() so far.

The statistics infrastructure itself uses a clock only for time stamps
that tell users what time a statistic has been switched on/off and reset.
This is what you have spotted here.

(The other and more important requirement regards exploiters of the
statistics infrastructure. They need a clock to measure latencies,
which they can report then.)

Regarding those time stamps, I think it best to make them look like other
timestamps, specifically the printk() time stamps in order not to confuse
users. That is why, one of my patches introduces nsec_to_timestamp()
based on some lines from printk(). Printk() uses printk_clock() as
source, which is nothing else than a sched_clock() call, unless
reimpelmented by architectures (only done for ia64).
If I want similar timestamps, I need the same time source too.

Now my question:

Would I get away with making printk_clock() a timestamp_clock() that
should be used by anyone exporting nsec_to_timestamp()-formated time
stamps to user space, including me?

I would then continue to see the use of sched_clock() in printk_clock()
... aehm timestamp_clock() as somebody else's problem (or at least
as a subordinate problem).
Thoughts?  <ducking down>

Martin