All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Robert Schöne" <robert.schoene@tu-dresden.de>
To: Arjan van de Ven <arjan@linux.intel.com>
Cc: Thomas Renninger <trenn@suse.de>, Dave Jones <davej@redhat.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@redhat.com>,
	linux-kernel <linux-kernel@vger.kernel.org>,
	cpufreq <cpufreq@vger.kernel.org>,
	x86@kernel.org
Subject: Re: [PATCH] trace power_frequency events on the correct cpu  (for Intel x86 CPUs)
Date: Tue, 30 Mar 2010 07:46:55 +0200	[thread overview]
Message-ID: <1269928015.3384.2.camel@localhost> (raw)
In-Reply-To: <1269414437.3355.6.camel@localhost>

Am Mittwoch, den 24.03.2010, 08:07 +0100 schrieb Robert Schöne:
> Am Dienstag, den 23.03.2010, 09:58 -0700 schrieb Arjan van de Ven:
> > On 3/23/2010 9:57, Thomas Renninger wrote:
> > > On Tuesday 23 March 2010 17:28:36 Robert Schöne wrote:
> > >> Am Montag, den 22.03.2010, 06:57 -0700 schrieb Arjan van de Ven:
> > >>> On 3/22/2010 0:04, Robert Schöne wrote:
> > >>>> Am Sonntag, den 21.03.2010, 17:42 -0700 schrieb Arjan van de Ven:
> > >>>>> On 3/20/2010 14:37, Thomas Renninger wrote:
> > >>>>>
> > >>>>>> It also seem to be (hopefully) a minor feature for timechart, so this should
> > >>>>>> not hurt that much (yet).
> > >>>>>
> > >>>>> It's actually a major feature for timechart, and one of the key things I and a bunch of others
> > >>>>> inside Intel use timechart for.
> > >>>>>
> > >>>> It's a major feature for us too.
> > >>>> I suppose, the cpufreq_notify_transition calls are correct (meaning
> > >>>> being called for all related cpus) for every driver. So there's still
> > >>>> the option to include it in the POST_CHANGE section of this function.
> > >>>> Could this be okay for the both of you?
> > >>>
> > >>> post change would work... that gets frequency afaik..
> > >> Are you ok with this too, Thomas?
> > > You mean hooking it into cpufreq_stat_notifier_trans() in
> > > drivers/cpufreq/cpufreq_stats.c?
> > 
> > no
> > 
> > 
> > hooking into the post frequency change callback that gets done..
> > which is guaranteed to be on the right cpu afaics.
> > 
> I don't see where this would be guaranteed. So I'd be fine with
> a) adding it to
> cpufreq.c/cpufreq_notify_transition/cpufreq_notify_transition
> 
> b) adding an item to the cpufreq_transition_notifier_list
> 
> c) adding it to cpufreq_stats.c/cpufreq_stat_notifier_trans
> 
> which would imply the usage of smp_call_function_single(...)
> 
I really want to keep this diskussion alive until there's a soultion we
can all agree.
So Arjan and Thomas, are there any comments/preferences to the proposed
options?



  reply	other threads:[~2010-03-30  5:47 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-03-12 13:17 [PATCH] trace power_frequency events on the correct cpu (for Intel x86 CPUs) Robert Schöne
2010-03-12 14:52 ` Arjan van de Ven
2010-03-12 15:41   ` Robert Schöne
2010-03-15 10:51     ` Thomas Renninger
2010-03-16  7:13       ` Robert Schöne
2010-03-16  9:57         ` Ingo Molnar
2010-03-16 10:59         ` Thomas Renninger
2010-03-16 14:19           ` Arjan van de Ven
2010-03-16 14:50             ` Thomas Renninger
2010-03-16 16:40               ` Arjan van de Ven
2010-03-17 16:36                 ` Thomas Renninger
2010-03-17 16:41                   ` Arjan van de Ven
2010-03-18 20:43                     ` Thomas Renninger
2010-03-19  8:01                       ` Robert Schöne
2010-03-20 21:37                         ` Thomas Renninger
2010-03-22  0:42                           ` Arjan van de Ven
2010-03-22  7:04                             ` Robert Schöne
2010-03-22 13:57                               ` Arjan van de Ven
2010-03-23 16:28                                 ` Robert Schöne
2010-03-23 16:57                                   ` Thomas Renninger
2010-03-23 16:58                                     ` Arjan van de Ven
2010-03-24  7:07                                       ` Robert Schöne
2010-03-30  5:46                                         ` Robert Schöne [this message]
2010-03-30  8:56                                           ` Thomas Renninger
2010-03-31  6:40                                             ` Robert Schöne
2010-04-12  6:53                                               ` Robert Schöne

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=1269928015.3384.2.camel@localhost \
    --to=robert.schoene@tu-dresden.de \
    --cc=arjan@linux.intel.com \
    --cc=cpufreq@vger.kernel.org \
    --cc=davej@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=tglx@linutronix.de \
    --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 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.