RE: CONFIG_PRINTK_TIME woes

[tony . luck]

Andrew Morton wrote:
>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.

The majority of architectures currently use a sched_clock() that
just scales jiffies (but that may just mean they haven't gotten around
to implementing anything better yet).

But how much resolution we need is a very good question, as it will
affect our choice of clock.

In many cases I've been presented with a console log which has a
few warning messages, and then an OOPS ... the initial question
I would like to answer is were the warnings printed "just before"
the oops ... or days earlier.  For these cases having a 1 second
resolution would be a huge bonus over no time information at all.
Jiffies would be good enough for almost all cases (IMO).

At the other extreme ... the current use of sched_clock() with
potentially nano-second resolution is way over the top.  Logging
to a serial console at 115200 a typical line from printk will take
2-4 milli-seconds to print ... so there would seem to be little
benefit from a sub-millisecond resolution (in fact at 250HZ jiffies
are on the ragged edge of being good enough).

If that isn't sufficient ... it should be possible to make a cut-down,
lockless version of do_gettimeofday that meets Andrew's suggestion
of good resolution with occasional theoretical weirdness.  But before
we go there ... I'd like to hear whether there are usage models that
really need better resolution than jiffies can provide?

-Tony
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/