>From [EMAIL PROTECTED] Wed Dec 20 02:36:15 2006
Distangle the NTP update from HZ. This is necessary for dynamic tick
enabled kernels.
---
include/linux/timex.h |7 +++
kernel/hrtimer.c | 11 ---
kernel/time/ntp.c | 30 +++---
kernel/timer.c
Hi,
On Tuesday 02 January 2007 20:42, john stultz wrote:
> > tick_nsec doesn't require special treatment, in the middle term it's
> > obsolete anyway, it could be replaced with (current_tick_length() >>
> > TICK_LENGTH_SHIFT) and current_tick_length() being inlined.
>
> If NTP_INTERVAL_FREQ is di
Hi,
On Tuesday 02 January 2007 21:50, john stultz wrote:
> > > It should be called every NTP_INTERVAL_FREQ times, but occasionally
> > > it's off
>
> Wait, so second_overflow should be called every NTP_INTERVAL_FREQ times
> (instead of every second)? Surely that's not right.
But it is, that's th
On Tue, 2007-01-02 at 11:46 -0800, john stultz wrote:
> On Mon, 2007-01-01 at 19:29 +0100, Roman Zippel wrote:
> > On Wednesday 20 December 2006 02:54, john stultz wrote:
> >
> > > And here would be the follow on patch (again *untested*) for
> > > CONFIG_NO_HZ slowing the time accumulation down to
On Mon, 2007-01-01 at 19:29 +0100, Roman Zippel wrote:
> On Wednesday 20 December 2006 02:54, john stultz wrote:
>
> > And here would be the follow on patch (again *untested*) for
> > CONFIG_NO_HZ slowing the time accumulation down to once per second.
>
> Changing it to one creates a potential pr
On Mon, 2007-01-01 at 17:27 +0100, Roman Zippel wrote:
> On Wednesday 20 December 2006 02:32, john stultz wrote:
>
> > > I know and all you have to change in the ntp and some related code is to
> > > replace HZ there with a variable, thus make it changable, so you can
> > > increase the update int
On Wednesday 20 December 2006 02:54, john stultz wrote:
> And here would be the follow on patch (again *untested*) for
> CONFIG_NO_HZ slowing the time accumulation down to once per second.
Changing it to one creates a potential problem with calling second_overflow().
It should be called every NT
Hi,
On Wednesday 20 December 2006 02:32, john stultz wrote:
> > I know and all you have to change in the ntp and some related code is to
> > replace HZ there with a variable, thus make it changable, so you can
> > increase the update interval (i.e. it becomes 1s/hz instead of 1s/HZ).
>
> Untested
On Tue, 19 Dec 2006 17:54:18 -0800
john stultz <[EMAIL PROTECTED]> wrote:
> On Tue, 2006-12-19 at 17:32 -0800, john stultz wrote:
> > On Wed, 2006-12-13 at 21:40 +0100, Roman Zippel wrote:
> > > On Wed, 13 Dec 2006, john stultz wrote:
> > > > > You don't have to introduce anything new, it's tick_l
On Tue, 2006-12-19 at 17:32 -0800, john stultz wrote:
> On Wed, 2006-12-13 at 21:40 +0100, Roman Zippel wrote:
> > On Wed, 13 Dec 2006, john stultz wrote:
> > > > You don't have to introduce anything new, it's tick_length that changes
> > > > and HZ that becomes a variable in this function.
> > >
>
On Wed, 2006-12-13 at 21:40 +0100, Roman Zippel wrote:
> On Wed, 13 Dec 2006, john stultz wrote:
> > > You cannot choose arbitrary intervals otherwise you get other problems,
> > > e.g. with your patch time_offset handling is broken.
> >
> > I'm not seeing this yet. Any more details?
>
> time_offs
Hi,
On Wed, 13 Dec 2006, john stultz wrote:
> > The largest possible interval is freq cycles (or 1 second without
> > adjustments). That is the base interval and without redesigning NTP we
> > can't change that. This base interval can be subdivided into smaller
> > intervals for incremental updat
On Wed, 2006-12-13 at 14:47 +0100, Roman Zippel wrote:
> Hi,
>
> On Tue, 12 Dec 2006, john stultz wrote:
>
> > Basically INTERVAL_LENGTH_NSEC defines the NTP interval length that the
> > time code will use to accumulate with. In this patch I've pushed it out
> > to a full second, but it could be
On Wed, 2006-12-13 at 10:51 +0100, Ingo Molnar wrote:
> * john stultz <[EMAIL PROTECTED]> wrote:
>
> > On Wed, 2006-12-06 at 15:33 +0100, Roman Zippel wrote:
> > > On Wed, 6 Dec 2006, Ingo Molnar wrote:
> > > > i disagree with you and it's pretty low-impact anyway. There's still
> > > > quite many
Hi,
On Tue, 12 Dec 2006, john stultz wrote:
> Basically INTERVAL_LENGTH_NSEC defines the NTP interval length that the
> time code will use to accumulate with. In this patch I've pushed it out
> to a full second, but it could be set via config (NSEC_PER_SEC/HZ for
> regular systems, something larg
* john stultz <[EMAIL PROTECTED]> wrote:
> On Wed, 2006-12-06 at 15:33 +0100, Roman Zippel wrote:
> > On Wed, 6 Dec 2006, Ingo Molnar wrote:
> > > i disagree with you and it's pretty low-impact anyway. There's still
> > > quite many HZ/tick assumptions all around the time code (NTP being one
> >
On Wed, 2006-12-06 at 15:33 +0100, Roman Zippel wrote:
> On Wed, 6 Dec 2006, Ingo Molnar wrote:
> > i disagree with you and it's pretty low-impact anyway. There's still
> > quite many HZ/tick assumptions all around the time code (NTP being one
> > example), we'll deal with those via other patches.
17 matches
Mail list logo
