All of lore.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 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.