All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dmitry Torokhov <dtor_core@ameritech.net>
To: john stultz <johnstul@us.ibm.com>
Cc: Karol Kozimor <sziwan@hell.org.pl>, Andrew Morton <akpm@osdl.org>,
	lkml <linux-kernel@vger.kernel.org>,
	Arjan van de Ven <arjanv@redhat.com>, jw schultz <jw@pegasys.ws>
Subject: Re: [2.6.0-mm2] PM timer still has problems
Date: Wed, 7 Jan 2004 01:30:21 -0500	[thread overview]
Message-ID: <200401070130.21769.dtor_core@ameritech.net> (raw)
In-Reply-To: <1073377877.2752.38.camel@localhost>

On Tuesday 06 January 2004 03:31 am, john stultz wrote:
> On Sun, 2004-01-04 at 22:17, Dmitry Torokhov wrote:
> > I decided to go hpet way and use tsc in ACPI PM timer to do delay
> > stuff and monotonic clock.
>
> I think you have a valid point that as loops_per_jiffy isn't updated,
> delay_pmtmr() and delay_pit() are broken w/ CPUFREQ.
>
> However I don't understand using the TSC for montonic_clock. I have no
> clue why the HPET folks implemented it that way (likely my fault for
> not enough documentaiton), but I haven't had the time to try to clean
> up that code. And really, if your TSC is reliable enough for
> monotonic_clock, why are you using the pmtmr? :) Unless it specifically
> is resolving an issue, I'd drop that change.
>

I thought (it seems that I was mistaken) that the goal of monotonic_clock
is to privide high-resolution cheap timestamps that are guaranteed never
go back as there is no adjustments to the time. The normal clock it supposed
to be stable and accurate but probably give lower resolution. In case of
pmtmr vs. TSC seems to have higher resolution and is cheap so it was used.

Dmitry 


  reply	other threads:[~2004-01-07  6:30 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-12-30 20:48 [2.6.0-mm2] PM timer still has problems Karol Kozimor
2003-12-31  4:02 ` Andrew Morton
2004-01-04  0:44   ` Karol Kozimor
2004-01-05  6:17     ` Dmitry Torokhov
2004-01-05 12:18       ` Karol Kozimor
2004-01-06  8:31       ` john stultz
2004-01-07  6:30         ` Dmitry Torokhov [this message]
2004-01-07 17:01           ` john stultz
2004-03-29 15:44       ` Karol Kozimor
2004-01-05 22:11 ` john stultz
2004-01-05 22:17   ` Karol Kozimor
2004-01-05 22:32     ` john stultz
2004-01-05 22:54       ` Karol Kozimor
2004-01-05 23:18       ` Karol Kozimor
2004-01-05 23:30         ` john stultz
2004-01-06  4:32   ` Dmitry Torokhov
2004-01-17  1:54     ` Karol Kozimor
2004-01-24  0:55     ` Karol Kozimor

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200401070130.21769.dtor_core@ameritech.net \
    --to=dtor_core@ameritech.net \
    --cc=akpm@osdl.org \
    --cc=arjanv@redhat.com \
    --cc=johnstul@us.ibm.com \
    --cc=jw@pegasys.ws \
    --cc=linux-kernel@vger.kernel.org \
    --cc=sziwan@hell.org.pl \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.