On Thu, 2005-07-14 at 17:24 -0700, Linus Torvalds wrote: > > On Thu, 14 Jul 2005, Lee Revell wrote: > > Trust me. When I say that the right thing to do is to just have a fixed > (but high) HZ value, and just changing the timer rate, I'm -right-. > > I'm always right. This time I'm just even more right than usual.
Of course you are, jiffies are simple and efficient. But it may be worthwhile to provide better/simpler API for relative timeouts and also better hide the implementation details of the tick system. If i sum-up the discussion from my POV: - use a 32-bit tick counter on 32-bit platforms and use a 64-bit counter on 64-bit platforms - keep the constant HZ=1000 (mS resolution) on 32-bit platforms - remove the assumption that timer interrupts and jiffies are 1:1 thing (jiffies may be incremented by >1 ticks at timer interrupt) - determine jiffies_increment at boot - have a slow clock mode to help power management (adjust jiffies_increment by the slowdown factor) - it may be useful to bump up HZ to 1e6 (uS res.) or 1e9 (nS res.) on 64-bit platforms, if there are benefits such as better accuracy during time units conversions or if a higher frequency timer hardware is available/viable. - it may be also useful to bump HZ on -RT (Real-time) kernels, or with -HRT (High-resolution timers support). Users of those kernel are willing to pay the cost of the overhead to have better resolution - avoid direct usage of the jiffies variable, instead use jiffies() (inline or MACRO), IMO monotonic_clock() would be a better name - provide a relative timeout API (see my previous post, or Alan's suggestions) - remove most of the direct use of jiffies through the code and replace them with msleep(), relative timer, etc - use human units for those APIs - Eric St-Laurent - 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/
