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: Mon, 12 Apr 2010 08:53:03 +0200	[thread overview]
Message-ID: <1271055183.3416.20.camel@localhost> (raw)
In-Reply-To: <1270017629.3428.31.camel@localhost>

Resend, to keep the diskussion alive
Am Mittwoch, den 31.03.2010, 08:40 +0200 schrieb Robert Schöne:
> Am Dienstag, den 30.03.2010, 09:56 +0100 schrieb Thomas Renninger:
> > On Tuesday 30 March 2010 07:46:55 Robert Schöne wrote:
> > ...
> > > 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?
> > I'd like to extend the powertracer and pass the cpu.
> > This is the only possibility I see to be able to support IO driven
> > frequency switching drivers where the switching code must not be executed
> > on the CPU that gets switched (without executing the tracer on each
> > CPU explicitly which does not make sense).
> As I understand you, you want to extend the event data of each power
> trace event, which would be fine for me.
> However, I think this would need some resorting of the events for the
> perf tools.
> @Arjan would this be feasible?
> > 
> > The next problem where current implementation is unfixable broken with
> > the tracer just passing the frequency is the fact that several CPUs
> > could get switched with one MSR write to a depending CPU (SW_ANY).
> > The same btw applies to C-states for which the tracer is used in
> > the same way (compare with 8.4.2.2 _CSD (C-State Dependency) of a
> > current ACPI spec).
> > 
> > No idea what the impact on userspace tools is, if I find some time
> > I can have a look at timechart how trace data gets read/used.
> > But I fear the Cstate tracing is used in some more tools already?
> > It would be great to get feedback/suggestions from people making use
> > of it already.
> > 
> > Below is still broken, but should make things at least a bit better:
> > 
> > ---
> > X86 cpufreq: Fix powertracer in acpi-cpufreq and exec it on the correct cpu(s)
> > 
> > Several things are broken with the tracer currently.
> > This patch fixes:
> >   - With the userspace governor the wrong cpu could get tracked if the target
> >     function is executed on a CPU which does not get switched
> >   - In SW_ALL CPU dependency case (CPUFREQ_SHARED_TYPE_ALL) only one CPU got
> >     tracked. Now all CPUs that depend on each other are tracked.
> > 
> > What this patch does not fix:
> >   - In SW_ANY case (CPUFREQ_SHARED_TYPE_ANY) it's enough to write to a MSR of
> >     one of the depending CPUs. The power trace macro misses the ability
> >     to pass the cpu. Thus only one of the depending CPUs gets tracked correctly.
> >     To be able to fix this the power trace macro must get extended.
> > 
> > 
> > Signed-off-by: Thomas Renninger <trenn@suse.de>
> > CC: Robert Schöne <robert.schoene@tu-dresden.de>
> > CC: x86@kernel.org
> > CC: cpufreq <cpufreq@vger.kernel.org>
> > CC: Arjan van de Ven <arjan@linux.intel.com>
> > CC: stable@kernel.org
> > 
> > ---
> >  arch/x86/kernel/cpu/cpufreq/acpi-cpufreq.c |    5 ++++-
> >  1 files changed, 4 insertions(+), 1 deletions(-)
> > 
> > diff --git a/arch/x86/kernel/cpu/cpufreq/acpi-cpufreq.c b/arch/x86/kernel/cpu/cpufreq/acpi-cpufreq.c
> > index 1b1920f..259c49e 100644
> > --- a/arch/x86/kernel/cpu/cpufreq/acpi-cpufreq.c
> > +++ b/arch/x86/kernel/cpu/cpufreq/acpi-cpufreq.c
> > @@ -144,6 +144,7 @@ struct drv_cmd {
> >  		struct io_addr io;
> >  	} addr;
> >  	u32 val;
> > +	unsigned int frequency;
> >  };
> >  
> >  /* Called via smp_call_function_single(), on the target CPU */
> > @@ -177,11 +178,13 @@ static void do_drv_write(void *_cmd)
> >  		rdmsr(cmd->addr.msr.reg, lo, hi);
> >  		lo = (lo & ~INTEL_MSR_RANGE) | (cmd->val & INTEL_MSR_RANGE);
> >  		wrmsr(cmd->addr.msr.reg, lo, hi);
> > +		trace_power_frequency(POWER_PSTATE, cmd->frequency);
> >  		break;
> >  	case SYSTEM_IO_CAPABLE:
> >  		acpi_os_write_port((acpi_io_address)cmd->addr.io.port,
> >  				cmd->val,
> >  				(u32)cmd->addr.io.bit_width);
> > +		trace_power_frequency(POWER_PSTATE, cmd->frequency);
> >  		break;
> >  	default:
> >  		break;
> > @@ -363,7 +366,7 @@ static int acpi_cpufreq_target(struct cpufreq_policy *policy,
> >  		}
> >  	}
> >  
> > -	trace_power_frequency(POWER_PSTATE, data->freq_table[next_state].frequency);
> > +	cmd.frequency = data->freq_table[next_state].frequency;
> >  
> >  	switch (data->cpu_feature) {
> >  	case SYSTEM_INTEL_MSR_CAPABLE:
> >   
> > 
> 
> 
> -- 
> Robert Schoene
> Technische Universitaet Dresden
> Zentrum fuer Informationsdienste und Hochleistungsrechnen
> 01062 Dresden
> 
> Tel.: (0351) 463-42483, Fax: (0351) 463-37773
> E-Mail: Robert.Schoene@tu-dresden.de
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 



      reply	other threads:[~2010-04-12  6:53 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
2010-03-30  8:56                                           ` Thomas Renninger
2010-03-31  6:40                                             ` Robert Schöne
2010-04-12  6:53                                               ` Robert Schöne [this message]

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=1271055183.3416.20.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.