cc:ing some timer hackers.
-------- Original Message --------
Subject: sched_clock() has poor resolution
Date: Tue, 20 Sep 2005 12:02:34 +0200
From: Pierre Ossman <[email protected]>
To: LKML <[email protected]>
I've been trying to hunt down a HZ bug and as part of that I thought
having printk timestamps would be nice. But too much dismay I noticed
that I couldn't get very good resolution out of these.
The problem turned out to be that sched_clock() uses jiffies as a time
source. It will only use the TSC if that's the primary time source of
the system. But since I have a PM timer that is given priority.
So I see two solutions here:
* Let sched_clock() follow the time source. Don't have it coupled to
the TSC.
* Init the TSC even though it isn't used for anything but sched_clock().
The first solution might have problems if one of the "better" timers are
slow as hell to read and the second if there is some assumed dependency
between sched_clock() and the primary timer. I'm blisfully ignorant of
this area so input is welcome.
Rgds
Pierre
Hi,
On Thu, Sep 22, 2005 at 09:28:49AM +0200, Pierre Ossman wrote:
> * Let sched_clock() follow the time source. Don't have it coupled to
> the TSC.
>
> * Init the TSC even though it isn't used for anything but sched_clock().
As pmtmr requires somewhat working TSCs, you can even use TSC if pmtmr is
used as a time source:
static int init_pmtmr(char* override)
...
/* we use the TSC for delay_pmtmr, so make sure it exists */
if (!cpu_has_tsc)
return -ENODEV;
...
So at least for this case, sched_clock() can and should use TSC, not
jiffies, AFAICS.
Thanks,
Dominik