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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/