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

From: Dipankar Sarma
Date: Tue Apr 05 2011 - 11:48:35 EST


On Tue, Apr 05, 2011 at 05:01:32PM +0200, Peter Zijlstra wrote:
> On Mon, 2011-04-04 at 20:02 +0530, Dipankar Sarma wrote:
> > On Fri, Apr 01, 2011 at 04:02:36PM +0200, Peter Zijlstra wrote:
> > I can't find any Moorestown documentation at the Intel site, but
> > thinking about Len's inputs a bit more, it seems there may
> > be still a problem asymetry from the scheduler perspective.
> >
> > If cpu0 or cpu1 either of them can be offlined, there is no
> > asymetry. If only cpu1 can be offlined, it would mean that
> > one cpu may be more efficient depending on how we do
> > cpu offlining for power savings. It gets a bit messy.
> >
> > Len, what exacty is the significance of offlining here ?
> > Apart from going to C6, what else is needed in cpu1 for
> > the chip to go to S0i3 ? Why is idle C6 not enough ?
>
> I don't think offlining is relevant, anybody using that for power
> management is doing it wrong, _very_ wrong.

I am suggesting that it depends on the offlining logic. If cpu1
is being used as an added co-processor for some specific apps
and mostly offline otherwise, it may not be an issue. If
offlining is being used as a meta-scheduler over the kernel
scheduler (like power savings or whatever logic) than it
will cause asymmetry problems dependent on the ooffline logic - e.g.
it may be more advantageous for the kernel scheduler to schedule
on cpu0 keeping cpu1 free leading to S0i3 more often. Not advocating
it when we are trying to run away from it on powerpc :)

For now, it seems we are OK in handling S0i3 through cpuidle, just that
it would be nice to understand the overall offline logic and why it is
needed. Similar questions have come up in my discussions with ARM guys
in the recent times as well.

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/