Hi.
On Wed, 2005-02-02 at 13:00, john stultz wrote:
> On Tue, 2005-02-01 at 17:48 -0800, Tim Bird wrote:
> > john stultz wrote:
> > > Interesting patch. Indeed, the trade off is just how quickly you want to
> > > boot vs how much drift you gain each suspend/resume cycle. Assuming all
> > > of the
On Tue, 2005-02-01 at 17:48 -0800, Tim Bird wrote:
> john stultz wrote:
> > Interesting patch. Indeed, the trade off is just how quickly you want to
> > boot vs how much drift you gain each suspend/resume cycle. Assuming all
> > of the clocks are good, your patch could introduce up to 2 seconds of
john stultz wrote:
> Interesting patch. Indeed, the trade off is just how quickly you want to
> boot vs how much drift you gain each suspend/resume cycle. Assuming all
> of the clocks are good, your patch could introduce up to 2 seconds of
> drift each suspend/resume cycle.
If we're not writing t
Hi.
On Wed, 2005-02-02 at 11:27, john stultz wrote:
> > We call the suspend and resume methods because the suspend is supposed
> > to achieve atomicity, and the resume is necessary for us to be able to
> > write the image. (Remember that these calls are invoked as part of the
> > drivers_suspend a
On Wed, 2005-02-02 at 11:04 +1100, Nigel Cunningham wrote:
> Hi.
>
> On Wed, 2005-02-02 at 10:32, john stultz wrote:
> > interesting, I wasn't aware of the suspend/copy/resume process that
> > occurs for suspend-to-disk. The thing I don't quite get is why are the
> > resume methods called before w
On Tue, 2005-02-01 at 15:53 -0800, Tim Bird wrote:
> john stultz wrote:
> > I believe you're right. Although we don't call read_persistent_clock()
> > very frequently, nor do we call it in ways we don't already call
> > get_cmos_time(). So I'm not sure exactly what the concern is.
>
> Sorry - I sh
Hi.
On Wed, 2005-02-02 at 10:32, john stultz wrote:
> On Wed, 2005-02-02 at 10:14 +1100, Nigel Cunningham wrote:
> > Hi John and Tim.
> >
> > On Wed, 2005-02-02 at 09:48, john stultz wrote:
> > > > I didn't scan for all uses of read_persistent_clock, but
> > > > in my experience get_cmos_time() h
john stultz wrote:
> I believe you're right. Although we don't call read_persistent_clock()
> very frequently, nor do we call it in ways we don't already call
> get_cmos_time(). So I'm not sure exactly what the concern is.
Sorry - I should have given more context. I am worried about
suspend and r
On Wed, 2005-02-02 at 10:14 +1100, Nigel Cunningham wrote:
> Hi John and Tim.
>
> On Wed, 2005-02-02 at 09:48, john stultz wrote:
> > > I didn't scan for all uses of read_persistent_clock, but
> > > in my experience get_cmos_time() has a latency of up to
> > > 1 second on x86 because it synchroniz
Hi John and Tim.
On Wed, 2005-02-02 at 09:48, john stultz wrote:
> > I didn't scan for all uses of read_persistent_clock, but
> > in my experience get_cmos_time() has a latency of up to
> > 1 second on x86 because it synchronizes with the rollover
> > of the RTC seconds.
>
> I believe you're righ
On Tue, 2005-02-01 at 14:06 -0800, Tim Bird wrote:
> Minor spelling fix, and a question.
>
> john stultz wrote:
> > linux-2.6.11-rc2_timeofday-core_A2.patch
> >
> > diff -Nru a/drivers/Makefile b/drivers/Makefile
> > --- a/drivers/Makefile 2005-01-24 1
Minor spelling fix, and a question.
john stultz wrote:
> linux-2.6.11-rc2_timeofday-core_A2.patch
>
> diff -Nru a/drivers/Makefile b/drivers/Makefile
> --- a/drivers/Makefile2005-01-24 13:30:06 -08:00
> +++ b/drivers/Makefile2005-01-24 13:30
On Tue, 2005-01-25 at 09:17 +0100, Andi Kleen wrote:
> On Mon, Jan 24, 2005 at 02:51:29PM -0800, john stultz wrote:
> > All,
> > Here is a new release of my time of day proposal, which include ppc64
> > support as well as suspend/resume and cpufreq hooks. For basic summary
> > of my ideas, you
> Monotonic clocks could be calculated
>
> monotime = ns_at_last_tick + (time_source_cycles_since_tick *
> current_scaling_factor) >> shift_factor.
>
> This would also be easy to implement in asm if necessary.
>
> tick processing could then increment or decrement the current scaling
> factor to
On Mon, Jan 24, 2005 at 02:51:29PM -0800, john stultz wrote:
> All,
> Here is a new release of my time of day proposal, which include ppc64
> support as well as suspend/resume and cpufreq hooks. For basic summary
> of my ideas, you can follow this link: http://lwn.net/Articles/100665/
[...]
On 24 Jan 2005 at 17:54, Christoph Lameter wrote:
> On Mon, 24 Jan 2005, john stultz wrote:
>
> > We talked about this last time. I do intend to re-work ntp_scale() so
> > its not a function call, much as you describe above.
> >
> > hopelessly endeavoring,
>
> hehe But seriously: The easiest
On 24 Jan 2005 at 15:24, Christoph Lameter wrote:
> On Mon, 24 Jan 2005, john stultz wrote:
>
> > +/* __monotonic_clock():
> > + * private function, must hold system_time_lock lock when being
> > + * called. Returns the monotonically increasing number of
> > + * nanosecond
On Mon, 24 Jan 2005, john stultz wrote:
> We talked about this last time. I do intend to re-work ntp_scale() so
> its not a function call, much as you describe above.
>
> hopelessly endeavoring,
hehe But seriously: The easiest approach may be to modify the time
sources to allow a fine tuning
On Mon, 2005-01-24 at 16:08 -0800, Christoph Lameter wrote:
> On Mon, 24 Jan 2005, john stultz wrote:
> > Yep, performance is a big concern. Re-working ntp_scale() is still on my
> > TODO list. I just didn't get to it in this release.
>
> This is a hopeless endeavor if you look at the function.
>
On Mon, 2005-01-24 at 15:24 -0800, Christoph Lameter wrote:
> On Mon, 24 Jan 2005, john stultz wrote:
> > + /* convert to nanoseconds */
> > + ns_offset = cyc2ns(timesource, delta, NULL);
> > +
> > + /* apply the NTP scaling */
> > + ns_offset = ntp_scale(ns_offset);
>
> The monotonic cloc
On Mon, 24 Jan 2005, john stultz wrote:
> Yep, performance is a big concern. Re-working ntp_scale() is still on my
> TODO list. I just didn't get to it in this release.
This is a hopeless endeavor if you look at the function.
Throw ntp_scale out and calculate a scaling factor during the ticks. At
On Mon, 24 Jan 2005, john stultz wrote:
> +/* __monotonic_clock():
> + * private function, must hold system_time_lock lock when being
> + * called. Returns the monotonically increasing number of
> + * nanoseconds since the system booted (adjusted by NTP
> scaling
All,
Here is a new release of my time of day proposal, which include ppc64
support as well as suspend/resume and cpufreq hooks. For basic summary
of my ideas, you can follow this link: http://lwn.net/Articles/100665/
This patch implements the architecture independent portion of the
23 matches
Mail list logo
