Re: cpuidle asymmetry (was Re: [RFC PATCH V4 5/5] cpuidle: cpuidledriver for apm)

From: Dipankar Sarma
Date: Sun Apr 03 2011 - 12:19:30 EST


On Fri, Apr 01, 2011 at 07:38:23AM -0700, Arjan van de Ven wrote:
> On 4/1/2011 1:15 AM, Dipankar Sarma wrote:
> >On Fri, Apr 01, 2011 at 12:09:25AM -0400, Len Brown wrote:
> >>>>Moorestown is already an example of an asymmetric system,
> >>>>since its deepest c-state is available on cpu0, but not on cpu1.
> >>>>So it needs different tables for each cpu.
> >>>wtf are these hardware guys smoking and how the heck are we supposed to
> >>>schedule on such a machine? Prefer to keep cpu1 busy while idling cpu0?
> >>they are smoking micro-amps:-)
> >>
> >>S0i3 on cpu0 can be entered only after cpu1 is already off-line,
> >>among other system hardware dependencies...
> >>
> >>So it makes no sense to export S0i3 as a c-state on cpu1.
> >>
> >>When cpu1 is online, the scheduler treats it as a normal SMP.
> >Isn't S0i3 a "system" state, as opposed to cpu state ?
>
> it's misnamed. it's a C state to the OS.

I understand that it has been implemented as a C-state from this -
http://build.meego.com/package/view_file?file=linux-2.6.37-mrst-s0i3.patch&package=kernel-adaptation-mrst&project=home%3Adliu9&srcmd5=a0929a2863150f5c8454507d6cd8f09d

The key question is this -

+int mrst_check_state_availability(struct cpuidle_device *dev)
+{
+ int cpu = smp_processor_id();
+
+ /*
+ * If there is another CPU running, the GPU is active,
+ * the PMU is uninitialized, or there is a still-unprocessed
+ * PMU command, we cannot enter S0i3.
+ */
+ if (!pmu_reg || !cpumask_equal(cpu_online_mask, cpumask_of(cpu)) ||
+ s0i3_pmu_command_pending)
+ dev->states[5].flags |= CPUIDLE_FLAG_IGNORE;
+ else
+ dev->states[5].flags &= ~CPUIDLE_FLAG_IGNORE;

Is this really asymetric ? Or is it that if the other
cpu(s) are in C6, the chip can enter S0i3 ? If that is the case,
then isn't this equivalent to all the cpus in the chip
entering S0i3 and thus symmetrical ? Also, if going to S0i3
relies on other cpus offlined, then we don't need to
worry about asymetry from the scheduler/cpuidle point of
view, no ?

Thanks
Dipankar
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/