public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Borislav Petkov <bp@amd64.org>
To: Thomas Renninger <trenn@suse.de>
Cc: akpm@linux-foundation.org, davej@redhat.com,
	cpufreq@vger.kernel.org, x86@kernel.org,
	linux-kernel@vger.kernel.org, "H. Peter Anvin" <hpa@zytor.com>
Subject: Re: [PATCH 2/5] powernow-k8: Add core performance boost support
Date: Tue, 23 Mar 2010 12:58:58 +0100	[thread overview]
Message-ID: <20100323115858.GC16493@aftab> (raw)
In-Reply-To: <201003231217.16451.trenn@suse.de>

(Adding hpa to Cc)

From: Thomas Renninger <trenn@suse.de>
Date: Tue, Mar 23, 2010 at 12:17:16PM +0100

> > +/* core performance boost */
> > +static bool cpb_capable, cpb_disabled;
> Whatabout using a cpufeature (arch/x86/include/asm/cpufeature.h)
> instead of cpb_capable. Then people could see this feature in 
> /proc/cpuinfo and other code parts could check for it easily if
> needed later.

I don't have a problem with that per se. It's just that /proc/cpuinfo
is a widely used interface and, AFAIR, changing it is not taken that
lightly.

Peter, what do you think?

> It could already be set in arch/x86/kernel/cpu/amd.c and
> powernow-k8 could use cpu_has(cpu, X86_FEATURE_CPB);

I'd still like to cache the cpb_capable value locally instead of getting
x86_cpuinfo percpu var and querying it. Especially if this happens often
and not only at driver init.

> Instead of cpb_disabled, I'd use cpb_enabled. Checking for
> !cpb_disabled whether it's enabled, is ugly to read.

Fair enough, cpb_disabled reflects the bit semantics in the MSR but why
not, don't matter which to me.

[..]

> > +		_cpb_toggle_msrs(t);
> > +		printk(KERN_INFO PFX "Core Boosting enabled.\n");
> Always printk on every toggle?
> That should not happen often and a user might want to get noticed if
> an app does this behind his back -> should be fine w/ or w/o, just not 
> sure whether it's intended.

Well, actually, this should be on by default and the user or an app
shouldn't be fidgeting with it all the time. It's there only for
benchmarking purposes so that you can disable it when you really have
to. But I guess it actually is going to get used if its there so maybe
we should have to rethink our approach. Hmm...

-- 
Regards/Gruss,
Boris.

--
Advanced Micro Devices, Inc.
Operating Systems Research Center

  reply	other threads:[~2010-03-23 11:58 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-03-22 18:38 [PATCH 0/5] powernow-k8: Core Performance Boost and effective frequency support Borislav Petkov
2010-03-22 18:38 ` [PATCH 1/5] cpufreq: Unify sysfs attribute definition macros Borislav Petkov
2010-03-23 11:07   ` Thomas Renninger
2010-03-23 11:44     ` Borislav Petkov
2010-03-23 11:55       ` Thomas Renninger
2010-03-23 12:05         ` Borislav Petkov
2010-03-23 12:30           ` Thomas Renninger
2010-03-22 18:38 ` [PATCH 2/5] powernow-k8: Add core performance boost support Borislav Petkov
2010-03-23 11:17   ` Thomas Renninger
2010-03-23 11:58     ` Borislav Petkov [this message]
2010-03-23 13:27       ` Dominik Brodowski
2010-03-23 14:19         ` Borislav Petkov
2010-03-23 14:47           ` Dominik Brodowski
2010-03-23 16:26             ` Borislav Petkov
2010-03-22 18:38 ` [PATCH 3/5] cpufreq: Add APERF/MPERF support for AMD processors Borislav Petkov
2010-03-23 11:26   ` Thomas Renninger
2010-03-23 11:59     ` Borislav Petkov
2010-03-22 18:38 ` [PATCH 4/5] powernow-k8: Fix frequency reporting Borislav Petkov
2010-03-22 18:38 ` [PATCH 5/5] cpufreq: Add support for actual freq Borislav Petkov
2010-03-23 11:51   ` Thomas Renninger
2010-03-23 14:23     ` Borislav Petkov
2010-03-23 14:41       ` Dominik Brodowski
2010-03-23 15:12       ` Thomas Renninger
2010-03-24 14:02         ` Borislav Petkov
  -- strict thread matches above, loose matches on Subject: below --
2010-03-24 17:46 [PATCH 0/5] powernow-k8: Core Performance Boost and effective frequency support Borislav Petkov
2010-03-24 17:46 ` [PATCH 2/5] powernow-k8: Add core performance boost support Borislav Petkov

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=20100323115858.GC16493@aftab \
    --to=bp@amd64.org \
    --cc=akpm@linux-foundation.org \
    --cc=cpufreq@vger.kernel.org \
    --cc=davej@redhat.com \
    --cc=hpa@zytor.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=trenn@suse.de \
    --cc=x86@kernel.org \
    /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