[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1A7043D5F58CCB44A599DFD55ED4C948452D3706@FMSMSX106.amr.corp.intel.com>
Date: Sat, 1 Feb 2014 19:39:29 +0000
From: "Brown, Len" <len.brown@...el.com>
To: Nicolas Pitre <nicolas.pitre@...aro.org>
CC: Arjan van de Ven <arjan@...ux.intel.com>,
Daniel Lezcano <daniel.lezcano@...aro.org>,
Preeti U Murthy <preeti@...ux.vnet.ibm.com>,
Peter Zijlstra <peterz@...radead.org>,
Preeti Murthy <preeti.lkml@...il.com>,
"mingo@...hat.com" <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
> And your point is?
It is a bad idea for an individual CPU to track the C-state
of another CPU, which can change the cycle after it was checked.
We know it is a bad idea because we used to do it,
until we realized code here can easily impact the
performance critical path.
In general, it is the OS's job to communicate constraints
to the HW, and the HW to act on them. Not all HW is smart,
so sometimes the OS has to do more hand-holding -- but
less is more.
thanks,
-Len
--
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