>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
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
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
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 different
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 the reason
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
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
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
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 interval
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 problem
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 once per
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
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).
>
>
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 patch
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
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
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_length that
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?
>
>
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_offset is scaled
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.
So, forgive
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
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
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
* 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
> >
* 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
example),
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 larger
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 HZ/tick
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 set via
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 updates.
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.
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.
Why
34 matches
Mail list logo
