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/