[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20080305175339.2059226b@mjolnir.drzeus.cx>
Date: Wed, 5 Mar 2008 17:53:39 +0100
From: Pierre Ossman <drzeus-list@...eus.cx>
To: Andi Kleen <andi@...stfloor.org>
Cc: Andi Kleen <andi@...stfloor.org>,
"Pallipadi, Venkatesh" <venkatesh.pallipadi@...el.com>,
Dave Jones <davej@...emonkey.org.uk>,
Alan Stern <stern@...land.harvard.edu>,
LKML <linux-kernel@...r.kernel.org>,
Adam Belay <abelay@...ell.com>,
Lee Revell <rlrevell@...-job.com>,
linux-pm@...ts.linux-foundation.org, Pavel Machek <pavel@....cz>
Subject: Re: [linux-pm] [PATCH] cpuidle: avoid singing capacitors
On Wed, 5 Mar 2008 16:48:56 +0100
Andi Kleen <andi@...stfloor.org> wrote:
>
> Start: You discovered at some point where you currently have code a variable
> is not updated yet.
> Fact: You have some new code that runs before that point
> Information: The variable is updated later eventually in the idle exit path.
> Fact II: You require the variable to be updated in your new code
For some value of "require". The code will do what it's supposed to do anyway, just in a sub-optimal way (it will avoid a deep sleep even though it didn't need to).
> Possible solutions:
> (1) you move your new code in a point of the idle exit path after the variable
> is updated
But I don't use jiffies in the idle exit path, only the entry path.
> (2) you move the code that updates the variable earlier before your code
Which basically leaves this option. I.e. guarantee that jiffies are updated between one cpuidle reflect and the subsequent select.
> Solution: I described the first variant which is likely easier.
> How: I told you where it is updated, so that shouldn't be too difficult.
> Action: Implement solution (1) or (2)
> Action: Test if it works
> Check: If test succeeded exit
> Otherwise: Restart at Start
>
Now you're just being a smart-ass. :)
--
-- Pierre Ossman
Linux kernel, MMC maintainer http://www.kernel.org
PulseAudio, core developer http://pulseaudio.org
rdesktop, core developer http://www.rdesktop.org
--
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