trace power_frequency events on the correct cpu (for Intel x86 CPUs)
in [Kernel]
|
Prev: [PATCH -v2] x86, k8 nb: Enable k8_northbridges unconditionally on AMD
Next: [RFC] resource, PCI: work around pci=use_crs conflicts
From: Arjan van de Ven on 16 Mar 2010 12:50 On 3/16/2010 7:50, Thomas Renninger wrote: > Still, as this is totally broken: > - by design -> only one of a dozen cpufreq drivers is supported the one I care about is supported. The others... anyone can add support for their favorite driver. > please submit my patch and remove this again until a proper > implementation is provided. how about not. it works right now, and is in active use right now. feel free to add support to other drivers if you care about those.... -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Arjan van de Ven on 17 Mar 2010 12:50 On 3/17/2010 9:36, Thomas Renninger wrote: > On Tuesday 16 March 2010 17:40:18 Arjan van de Ven wrote: >> On 3/16/2010 7:50, Thomas Renninger wrote: >>> Still, as this is totally broken: >>> - by design -> only one of a dozen cpufreq drivers is supported >> >> the one I care about is supported. > And that's the problem, before it's not removed, you do not care to > provide/suggest a proper solution that could fit others as well. why don't you provide the others then? >> how about not. it works right now, > It does not. Robert's fix (if he had taken the frequency) is correct. > That means you could get totally wrong values > when you put some load on the machine and the scheduler moves around > processes. the only case where the bug can hit is the userspace governor, yes. it works correct for everything else. Yes it wants fixing. No it does not make all data from it worthless. >> and is in active use right now. > It's obviously not powertop, there I get some statistics on an AMD > machine as well. So where does it get used? as I wrote in my previous mails... timechart. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Robert Schöne on 19 Mar 2010 04:10 Am Donnerstag, den 18.03.2010, 21:43 +0100 schrieb Thomas Renninger: > On Wednesday 17 March 2010 05:41:38 pm Arjan van de Ven wrote: > > On 3/17/2010 9:36, Thomas Renninger wrote: > > > On Tuesday 16 March 2010 17:40:18 Arjan van de Ven wrote: > > >> On 3/16/2010 7:50, Thomas Renninger wrote: > > >>> Still, as this is totally broken: > > >>> - by design -> only one of a dozen cpufreq drivers is supported > > >> > > >> the one I care about is supported. > > > > > > And that's the problem, before it's not removed, you do not care to > > > provide/suggest a proper solution that could fit others as well. > > > > why don't you provide the others then? > Is it possible somehow to provide a kind of wrapper/backup function: > trace_power_frequency_cpu(POWER_PSTATE, frequency, cpu); As I understood the tracing correctly this would imply the usage of smp_call_function_single which should be aoided. > or another trace interface with eventually some more overhead? > Then it should be easy to support all drivers. > Otherwise you'll for example miss the pcc driver which supports > latest/upcoming Intel CPUs and which does IO based switching which needs not > to run on the cpu that gets switched. > > Thomas This wrapper would make things easier of course, since one might add the same line for every driver. Or even call it from cpufreq_notify_transition (POSTCHANGE) which would add this event for other architectures then x86 (which I would approve). But - and here's the problem - the tracing infrastructure should provide as less overhead as possible. It should be called directly after writing the new frequency for the specific cpu and by this optimally in a funtion wich is already executed on the cpu. Otherwise the following might happen (4 cpu system): cpu 3 wants to change freq of cpu 0: .... switch to cpu 0 (some overhead) write new frequency switch back (some overhead) switch to cpu 0 (some overhead) write trace switch back (some overhead) .... It's easy to see, that writing of the frequency and writing the trace should be called directly one after another. It increases the accuracy of the trace and decreases the overhead. Robert -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Arjan van de Ven on 21 Mar 2010 20:50 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. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Robert Schöne on 22 Mar 2010 03:10
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? -- Robert Schoene Technische Universitaet Dresden Zentrum fuer Informationsdienste und Hochleistungsrechnen 01062 Dresden Tel.: (0351) 463-42483, Fax: (0351) 463-37773 E-Mail: Robert.Schoene(a)tu-dresden.de -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |