Re: HZ question

[Daniel Barkalow]

On Tue, 13 Sep 2005, Mark Hounschell wrote:

> Stefan Smietanowski wrote:
> > Mark Hounschell wrote:
> > > >Tim Schmielau wrote:
> > > >
> > > > >Do you also want to know about CONFIG_PREEMPT, SMP, current load,
> > > > >future
> > > > >load in order to estimate the delay you want to ask for?
> > > >
> > > >Are not CONFIG_PREEMPT, SMP, and current load, all determinable from
> > > >userland anyway? Why not HZ?
> > 
> > And with dynamic HZ?
> > 
> > Do you want
> > a) The HZ that was used when we booted
> > b) The HZ that is currently used (say 22, but could be 573 in 0.1s)
> > c) The MIN HZ (if there is such a thing and it is configured)
> >    that the kernel will use.
> > d) The MAX HZ (same) that the kernel will use.
> > 
> > Or do you want USER_HZ?
> > 
> > Or are you after something else entirely.
> > 
> > // Stefan
> 
> If dynamic HZ means dynamic timer resolutions I don't want it at all.
> 
> I guess the 'terms' John just used, ie timer resolutions, as opposed to
> HZ was maybe what I really should have asked for to begin with.
> 
> However since they are both bascially the same or at least one derived
> from the other......?

There's nothing to say that the kernel couldn't have hardware programmed 
to give an interrupt and schedule your process at some point that wouldn't 
normally be a scheduler tick. So the HRT interface could give you better 
than HZ. Also, there's the possibility that the kernel could slack off on 
HZ when you're not using HRT, and then there are patches for "tickless", 
where it just programs the timer for the next time something is scheduled 
to happen, and there's no fixed rate outside of actual activity.

	-Daniel
*This .sig left intentionally blank*
-
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/