public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: john stultz <johnstul@us.ibm.com>
To: dean gaudet <dean-list-linux-kernel@arctic.org>, linux@brodo.de
Cc: lkml <linux-kernel@vger.kernel.org>
Subject: Re: [patch] prefer TSC over PM Timer
Date: Tue, 16 Nov 2004 01:50:44 -0800	[thread overview]
Message-ID: <1100598645.13732.22.camel@leatherman> (raw)
In-Reply-To: <Pine.LNX.4.61.0411151843190.22091@twinlark.arctic.org>

On Mon, 2004-11-15 at 19:21 -0800, dean gaudet wrote:
> On Mon, 15 Nov 2004, john stultz wrote:
> > With your patch, ACPI PM would never be selected (as TSC always wins
> > when available, and it will be available on all ACPI enabled i386
> > systems). So its just the same as disabling CONFIG_X86_PM_TIMER, so why
> > not just do that?
> 
> my patch lets you use "clock=pmtmr" if you want it.

Yea, but at that point you have to enable it in the config and then pass
a boot parameter to use it.  I dunno. If you want to go with that you
should def include a comment in the pmtmr code as well as in the config
help. 

> > Do note, using the "clock=tsc" boot option, you can easily force the
> > system to use the TSC.
> 
> right -- except i think the default is the opposite of what it should be 
> for a generic kernel.  i think more systems are served better by using tsc 
> than those that need clock=pm...  NUMA systems are rare (with custom 
> kernels/etc), and if my experience with the centrino is valid then newer 
> laptops aren't having this tsc/cpufreq problem.
>
> > I would however, support a patch that selected the TSC over the ACPI PM
> > time source when CONFIG_CPUFREQ and CONFIG_SMP were N. That's fairly
> > safe. 
> 
> i'm looking for a solution that generic distribution kernels can use...
> 
> honestly my selfish motivation is to get efficeon/crusoe treated properly 
> -- they support a fixed TSC rate which does not vary with frequency (which 
> many people fault us for, but the reality is that fixed TSC is the only 
> viable solution for a processor which can vary power consumption without 
> the involvement of the kernel).  

Yea, I just wish we could get away from the TSC and have a well defined
and hardware guaranteed timebase register like PPC. 

> i'd advocate a patch like the one 
> below... but it feels wrong.

Yea, no, I definitely don't like that. I know how these tricks work,
send out a worse patch to make the first look better ;) But alas, you've
worn me down! Add the comments I mentioned above and I'd go along with
it. 

Dominik: are you cool with this?

thanks
-john


  reply	other threads:[~2004-11-16  9:53 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-11-16  0:23 [patch] prefer TSC over PM Timer dean gaudet
2004-11-16  1:38 ` john stultz
2004-11-16  3:21   ` dean gaudet
2004-11-16  9:50     ` john stultz [this message]
2004-11-16 20:29       ` Dominik Brodowski
2004-11-16 21:06         ` john stultz
2004-11-16  8:11   ` Arjan van de Ven
2004-11-16  9:36     ` john stultz
2004-11-17 15:25     ` Alan Cox
2004-11-17 15:25 ` Alan Cox
2004-11-17 17:23   ` Chris Friesen
  -- strict thread matches above, loose matches on Subject: below --
2004-11-16 18:27 Pallipadi, Venkatesh
2004-11-17  1:50 ` dean gaudet
2004-11-17 10:43   ` Mikael Pettersson
2004-11-17 14:19   ` Dmitry Torokhov
2004-11-17 15:31   ` Alan Cox
2004-11-18  2:01   ` Krzysztof Halasa
2004-11-17 15:08 Pallipadi, Venkatesh

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=1100598645.13732.22.camel@leatherman \
    --to=johnstul@us.ibm.com \
    --cc=dean-list-linux-kernel@arctic.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@brodo.de \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox