Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755385AbYJFU52 (ORCPT ); Mon, 6 Oct 2008 16:57:28 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1754342AbYJFU5T (ORCPT ); Mon, 6 Oct 2008 16:57:19 -0400 Received: from casper.infradead.org ([85.118.1.10]:58971 "EHLO casper.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754302AbYJFU5T (ORCPT ); Mon, 6 Oct 2008 16:57:19 -0400 Date: Mon, 6 Oct 2008 13:57:15 -0700 From: Arjan van de Ven To: Andi Kleen Cc: linux-kernel@vger.kernel.org, Steven Rostedt , mingo@elte.hu, Peter Zijlstra , lenb@kernel.org Subject: Re: PATCH] ftrace: Add a C/P state tracer to help power optimization Message-ID: <20081006135715.6a52e954@infradead.org> In-Reply-To: <87y711moz2.fsf@basil.nowhere.org> References: <20081006102640.481acd23@infradead.org> <87y711moz2.fsf@basil.nowhere.org> Organization: Intel X-Mailer: Claws Mail 3.5.0 (GTK+ 2.12.12; i386-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-SRS-Rewrite: SMTP reverse-path rewritten from by casper.infradead.org See http://www.infradead.org/rpr.html Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2075 Lines: 70 On Mon, 06 Oct 2008 22:46:09 +0200 Andi Kleen wrote: > > > > + trace_power_mark(&it, POWER_PSTATE, next_perf_state); > > Wouldn't that be better higher up in the cpufreq system? It would > seem bad to duplicate that in all low level cpufreq modules. the problem is that higher up the actual P state isn't known. > > Also I suspect some higher level format would be good here too. > Just put the frequency in? the link between P states and frequency is... rather lose. Especially with Turbo Mode it no longer is really relevant to list frequencies. > > + ret = trace_seq_printf(s, "[%5ld.%09ld] > > CSTATE: Going to C%i on cpu %i for %ld.%09ld\n", > > + stamp.tv_sec, > > + stamp.tv_nsec, > > + it->state, iter->cpu, > > + duration.tv_sec, > > + duration.tv_nsec); > > + if (it->type == POWER_PSTATE) > > + ret = trace_seq_printf(s, "[%5ld.%09ld] > > PSTATE: Going to P%i on cpu %i\n", > > + stamp.tv_sec, > > + stamp.tv_nsec, > > + it->state, iter->cpu); > > I suspect a less verbose output format would be better. why? It's fine as it is, and it's actually human readable as well. > > > +{ > > + if (!trace_power_enabled) > > + return; > > + > > + memset(it, 0, sizeof(struct power_trace)); > > The memset seems redundant. it's free and it initializes the datastructure cleanly; and only when the tracer is in use. > > 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? yes you're missing something ;-) this code is called when going out of idle, not when going into idle. -- Arjan van de Ven Intel Open Source Technology Centre For development, discussion and tips for power savings, visit http://www.lesswatts.org -- 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/