> On Wed, 26 Jan 2005 08:52:12 -0800 (PST), Christoph Lameter <[EMAIL
> PROTECTED]> said:
Christoph> On Wed, 26 Jan 2005, Martin Schwidefsky wrote:
>> Why not add an if at the start of gettimeofday to check when the
>> last ntp updates has been done and if it has been too long since
On Wed, 26 Jan 2005, Martin Schwidefsky wrote:
> Why not add an if at the start of gettimeofday to check when the last
> ntp updates has been done and if it has been too long since the last time
> then call ntp_scale ? That way the update isn't done on every call to
> gettimeofday and we don't dep
On Wed, 26 Jan 2005, Benjamin Herrenschmidt wrote:
> On Tue, 2005-01-25 at 16:34 -0800, Christoph Lameter wrote:
>
> > I just hope that the implementation of one arch does not become a standard
> > without sufficient reflection. Could we first get an explanation of
> > the rationale of the offset
On Tue, 2005-01-25 at 16:34 -0800, Christoph Lameter wrote:
> I just hope that the implementation of one arch does not become a standard
> without sufficient reflection. Could we first get an explanation of
> the rationale of the offsets? From my viewpoint of the ia64 implementation
> I have some
On Tue, 2005-01-25 at 16:17 -0800, john stultz wrote:
> Hmm. In my code, I move the interval delta (similar to your pre-scale
> offset) to system_time (seems to be equivalent to the post-scale) at
> each call to timeofday_interrupt_hook(). So while 64 bits are normally
> used, you could probably g
On Tue, 25 Jan 2005, john stultz wrote:
> Agreed. I'll get something like this done for the next release.
>
> > Well, since it only contains the prescale and postscale offsets and the
> > scaling value, it only needs to be updated when they change, so a hook
> > here would be fine.
>
> Great, that
On Wed, 2005-01-26 at 10:53 +1100, Benjamin Herrenschmidt wrote:
> On Tue, 2005-01-25 at 15:09 -0800, john stultz wrote:
>
> > The performance is a concern, and right now there are issues (ntp_scale
> > being the top of the list) however I hope they can be resolved. Looking
> > at ppc64's do_getti
On Tue, 2005-01-25 at 15:09 -0800, john stultz wrote:
> The performance is a concern, and right now there are issues (ntp_scale
> being the top of the list) however I hope they can be resolved. Looking
> at ppc64's do_gettimeofday() vs this implementation there we do have
> more overhead, but mayb
On Tue, 2005-01-25 at 13:28 +1100, Benjamin Herrenschmidt wrote:
> On Mon, 2005-01-24 at 14:52 -0800, john stultz wrote:
> > All,
> > This patch implements the minimal architecture specific hooks to enable
> > the new time of day subsystem code for i386, x86-64, and ppc64. It
> > applies on top
On Mon, 2005-01-24 at 14:52 -0800, john stultz wrote:
> All,
> This patch implements the minimal architecture specific hooks to enable
> the new time of day subsystem code for i386, x86-64, and ppc64. It
> applies on top of my linux-2.6.11-rc1_timeofday-core_A2 patch and with
> this patch app
All,
This patch implements the minimal architecture specific hooks to enable
the new time of day subsystem code for i386, x86-64, and ppc64. It
applies on top of my linux-2.6.11-rc1_timeofday-core_A2 patch and with
this patch applied, you can test the new time of day subsystem.
Ba
11 matches
Mail list logo
