Messages in this thread | | | Subject | Re: [PATCH] i386: Selectable Frequency of the Timer Interrupt | From | Eric St-Laurent <> | Date | Thu, 14 Jul 2005 22:00:55 -0400 |
| |
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 majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |