From: Arjan van de Ven on
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
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
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
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
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/