[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20140131102455.GB8874@twins.programming.kicks-ass.net>
Date: Fri, 31 Jan 2014 11:24:55 +0100
From: Peter Zijlstra <peterz@...radead.org>
To: Preeti U Murthy <preeti@...ux.vnet.ibm.com>
Cc: Arjan van de Ven <arjan@...ux.intel.com>,
Len Brown <len.brown@...el.com>,
Preeti Murthy <preeti.lkml@...il.com>,
Daniel Lezcano <daniel.lezcano@...aro.org>,
nicolas.pitre@...aro.org, mingo@...hat.com,
Thomas Gleixner <tglx@...utronix.de>,
"Rafael J. Wysocki" <rjw@...ysocki.net>,
LKML <linux-kernel@...r.kernel.org>,
"linux-pm@...r.kernel.org" <linux-pm@...r.kernel.org>,
Lists linaro-kernel <linaro-kernel@...ts.linaro.org>
Subject: Re: [RFC PATCH 3/3] idle: store the idle state index in the struct rq
On Fri, Jan 31, 2014 at 03:09:49PM +0530, Preeti U Murthy wrote:
> > Alternatively, can we enforce sanity on the cpuidle infrastructure to
> > make the index naturally ordered? If not, please explain why :-)
>
> The commit id 71abbbf856a0e70 says that there are SOCs which could have
> their target_residency and exit_latency values change at runtime. This
> commit thus removed the ordering of the idle states according to their
> target_residency/exit_latency. Adding Len and Arjan to the CC.
OK that changelog pretty much destroys the ordered index. In which case
we need pretty accessors for useable numbers.
It would be good to reduce the number of cachelines those touch, but I'm
not at all familiar with the cpuidle state...
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists