Andrew Morton wrote:
> Nick Piggin <[email protected]> wrote:
>>
>>What about just using jiffies, then?
>>
>>Really, sched_clock() is very broken for this (I know you're
>>not arguing against that).
>>
>>It can go backwards when called twice from the same CPU, and the
>>number returned by one CPU need have no correlation with that
>>returned by another.
>
> jiffies wouldn't have sufficient resolution for this application. Bear
> in
> mind that this is just a debugging thing - it's better to have good
> resolution with occasional theoretical weirdness than to have poor
> resolution plus super-consistency, IMO.
Andrew's assessment is correct for my usage.
I use this for detailed info on bootup times, for tuning embedded
configurations. Someone has already noted that the current code
truncates the value to microseconds (so a nanosecond-capable clock
interface is overkill for the current code). Microseconds seems
to be a pretty useful precision for the work I'm doing.
Note that on many embedded platforms, a jiffy is 10 milliseconds,
which is far too low resolution for my purposes. Also, not
to be totally egocentric, but most embedded platforms don't
have SMP (currently), so the SMP weirdness has never bothered
me. Even on SMP systems, the bootup code, which is what
I'm measuring, is mostly UP.
Just my 2 cents.
=============================
Tim Bird
Architecture Group Chair, CE Linux Forum
Senior Staff Engineer, Sony Electronics
=============================
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
| |
 |