Re: PATCH] ftrace: Add a C/P state tracer to help power optimization

Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]
From: Andi Kleen
Date: Monday, October 6, 2008 - 1:46 pm

Arjan van de Ven <arjan@infradead.org> writes:

This might be a subtle issue, but when someone starts synchronizing
their clocksource read with idle (which makes sense in some circumstances) 
then your timing will break because ktime_get() might be inaccurate directly 
coming out of idle before other code ran.

That's theoretical right now, but could be a real danger in the future.
  

Wouldn't that be better higher up in the cpufreq system?  It would
seem bad to duplicate that in all low level cpufreq modules.

Also I suspect some higher level format would be good here too.
Just put the frequency in? 


Reference to the required userland?


I suspect a less verbose output format would be better.


The memset seems redundant.



When ring_buffer_lock_reserve really disables interrupts (I haven't
checked since it's not in 2.6.27rc8) you could avoid the
preempt_disable by moving the data = tr->data ... one below.

Similar comments to trace_power_mark. Also it would be probably good 
to use a common function instead of duplicating so much code.



Hmm, that does a unconditional wake_up() in idle. Doesn't this cause a loop
on UP?

idle -> wakeup -> idle -> wakeup -> ... etc.

Am I missing something?


The cat is not needed

-Andi
-- 
ak@linux.intel.com
--
Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]

Messages in current thread:
Re: PATCH] ftrace: Add a C/P state tracer to help power op ..., Andi Kleen, (Mon Oct 6, 1:46 pm)
Re: PATCH] ftrace: Add a C/P state tracer to help power op ..., Arjan van de Ven, (Mon Oct 27, 11:05 am)
Re: PATCH] ftrace: Add a C/P state tracer to help power op ..., Frank Ch. Eigler, (Mon Oct 27, 12:47 pm)
Re: PATCH] ftrace: Add a C/P state tracer to help power op ..., Frederic Weisbecker, (Tue Feb 10, 2:26 pm)