diff mbox

[REGRESSION,FIX] x86 idle: restore mwait_idle()

Message ID 1390061684.5566.4.camel@marge.simpson.net (mailing list archive)
State Not Applicable, archived
Headers show

Commit Message

Mike Galbraith Jan. 18, 2014, 4:14 p.m. UTC
On Sat, 2014-01-18 at 10:33 +0100, Mike Galbraith wrote: 
> On Fri, 2014-01-17 at 05:20 +0100, Mike Galbraith wrote:
> 
> > taskset 0xc pipe-test 1
> > 
> > 3.8.13     3.397977 usecs/loop -- avg 3.400336 588.2 KHz
> > master+    4.798547 usecs/loop -- avg 4.791692 417.4 KHz
> 
> Bah, those are apple/grape, these are apple/apple.

Or, to make it more correct for 3.10..13, add the clflush barriers as
well for afflicted CPUs.

idle: kill unnecessary mwait_idle() resched IPIs

Set/clear polling instead.

Q6600, pipe-test scheduling cross core:
3.8.13                   487.2 KHz    1.000
3.13.0-master            415.5 KHz     .852
3.13.0-master+           415.2 KHz     .852     + restore mwait_idle
3.13.0-master++          488.5 KHz    1.002     + restore mwait_idle + IPI fix

Signed-off-by: Mike Galbraith <bitbucket@online.de>
Cc: <stable@vger.kernel.org> # 3.10+
---
 arch/x86/kernel/process.c |    9 ++++++---
 1 file changed, 6 insertions(+), 3 deletions(-)



--
To unsubscribe from this list: send the line "unsubscribe linux-pm" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Comments

Ian Malone March 14, 2015, 11:44 p.m. UTC | #1
On 18 January 2014 at 16:14, Mike Galbraith <bitbucket@online.de> wrote:
> On Sat, 2014-01-18 at 10:33 +0100, Mike Galbraith wrote:
>> On Fri, 2014-01-17 at 05:20 +0100, Mike Galbraith wrote:

> Signed-off-by: Mike Galbraith <bitbucket@online.de>
> Cc: <stable@vger.kernel.org> # 3.10+
> ---
>  arch/x86/kernel/process.c |    9 ++++++---
>  1 file changed, 6 insertions(+), 3 deletions(-)
>
> --- a/arch/x86/kernel/process.c
> +++ b/arch/x86/kernel/process.c
> @@ -427,18 +427,21 @@ static int prefer_mwait_c1_over_halt(con

Hi, this series of patches never seem to have made it as far as the
mainline kernel, anyone know what needs to happen next?
Mike Galbraith March 15, 2015, 4:53 a.m. UTC | #2
On Sat, 2015-03-14 at 23:44 +0000, Ian Malone wrote:
> On 18 January 2014 at 16:14, Mike Galbraith <bitbucket@online.de> wrote:
> > On Sat, 2014-01-18 at 10:33 +0100, Mike Galbraith wrote:
> >> On Fri, 2014-01-17 at 05:20 +0100, Mike Galbraith wrote:
> 
> > Signed-off-by: Mike Galbraith <bitbucket@online.de>
> > Cc: <stable@vger.kernel.org> # 3.10+
> > ---
> >  arch/x86/kernel/process.c |    9 ++++++---
> >  1 file changed, 6 insertions(+), 3 deletions(-)
> >
> > --- a/arch/x86/kernel/process.c
> > +++ b/arch/x86/kernel/process.c
> > @@ -427,18 +427,21 @@ static int prefer_mwait_c1_over_halt(con
> 
> Hi, this series of patches never seem to have made it as far as the
> mainline kernel, anyone know what needs to happen next?

My plan is to keep on carrying it locally for as long as I run new
kernels on crusty ole core2 boxen, then stop caring about them entirely
like the rest of the planet :)

	-Mike

--
To unsubscribe from this list: send the line "unsubscribe linux-pm" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Ian Malone March 16, 2015, 11:32 p.m. UTC | #3
On 15 March 2015 at 04:53, Mike Galbraith <umgwanakikbuti@gmail.com> wrote:
> On Sat, 2015-03-14 at 23:44 +0000, Ian Malone wrote:
>> On 18 January 2014 at 16:14, Mike Galbraith <bitbucket@online.de> wrote:
>> > On Sat, 2014-01-18 at 10:33 +0100, Mike Galbraith wrote:
>> >> On Fri, 2014-01-17 at 05:20 +0100, Mike Galbraith wrote:
>>
>> > Signed-off-by: Mike Galbraith <bitbucket@online.de>
>> > Cc: <stable@vger.kernel.org> # 3.10+
>> > ---
>> >  arch/x86/kernel/process.c |    9 ++++++---
>> >  1 file changed, 6 insertions(+), 3 deletions(-)
>> >
>> > --- a/arch/x86/kernel/process.c
>> > +++ b/arch/x86/kernel/process.c
>> > @@ -427,18 +427,21 @@ static int prefer_mwait_c1_over_halt(con
>>
>> Hi, this series of patches never seem to have made it as far as the
>> mainline kernel, anyone know what needs to happen next?
>
> My plan is to keep on carrying it locally for as long as I run new
> kernels on crusty ole core2 boxen, then stop caring about them entirely
> like the rest of the planet :)
>

Looks like Ingo Molnar has committed to tip which is probably a good
sign, thanks all.
(Have to hand this system on to someone who wont be patching kernels...)
Ingo Molnar March 17, 2015, 8:22 a.m. UTC | #4
* Ian Malone <ibmalone@gmail.com> wrote:

> On 15 March 2015 at 04:53, Mike Galbraith <umgwanakikbuti@gmail.com> wrote:
> > On Sat, 2015-03-14 at 23:44 +0000, Ian Malone wrote:
> >> On 18 January 2014 at 16:14, Mike Galbraith <bitbucket@online.de> wrote:
> >> > On Sat, 2014-01-18 at 10:33 +0100, Mike Galbraith wrote:
> >> >> On Fri, 2014-01-17 at 05:20 +0100, Mike Galbraith wrote:
> >>
> >> > Signed-off-by: Mike Galbraith <bitbucket@online.de>
> >> > Cc: <stable@vger.kernel.org> # 3.10+
> >> > ---
> >> >  arch/x86/kernel/process.c |    9 ++++++---
> >> >  1 file changed, 6 insertions(+), 3 deletions(-)
> >> >
> >> > --- a/arch/x86/kernel/process.c
> >> > +++ b/arch/x86/kernel/process.c
> >> > @@ -427,18 +427,21 @@ static int prefer_mwait_c1_over_halt(con
> >>
> >> Hi, this series of patches never seem to have made it as far as the
> >> mainline kernel, anyone know what needs to happen next?
> >
> > My plan is to keep on carrying it locally for as long as I run new
> > kernels on crusty ole core2 boxen, then stop caring about them entirely
> > like the rest of the planet :)
> >
> 
> Looks like Ingo Molnar has committed to tip which is probably a good
> sign, thanks all.
> (Have to hand this system on to someone who wont be patching kernels...)

Guys, since I don't have the affected hardware, mind testing the 
latest sched/core tree:

  git clone git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git
  cd tip
  git checkout sched/core
  # build a test kernel and boot it

Or if you already have a kernel git tree, do something like this to 
pick up the scheduler development tree:

  cd linux.git
  git remote add git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git tip
  git remote update
  git checkout tip/sched/core
  # build a test kernel and boot it

and check whether the mwait related bugs are now fixed for good?

Thanks,

	Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-pm" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Mike Galbraith March 17, 2015, 8:33 a.m. UTC | #5
On Tue, 2015-03-17 at 09:22 +0100, Ingo Molnar wrote:
> * Ian Malone <ibmalone@gmail.com> wrote:
> 
> > On 15 March 2015 at 04:53, Mike Galbraith <umgwanakikbuti@gmail.com> wrote:
> > > On Sat, 2015-03-14 at 23:44 +0000, Ian Malone wrote:
> > >> On 18 January 2014 at 16:14, Mike Galbraith <bitbucket@online.de> wrote:
> > >> > On Sat, 2014-01-18 at 10:33 +0100, Mike Galbraith wrote:
> > >> >> On Fri, 2014-01-17 at 05:20 +0100, Mike Galbraith wrote:
> > >>
> > >> > Signed-off-by: Mike Galbraith <bitbucket@online.de>
> > >> > Cc: <stable@vger.kernel.org> # 3.10+
> > >> > ---
> > >> >  arch/x86/kernel/process.c |    9 ++++++---
> > >> >  1 file changed, 6 insertions(+), 3 deletions(-)
> > >> >
> > >> > --- a/arch/x86/kernel/process.c
> > >> > +++ b/arch/x86/kernel/process.c
> > >> > @@ -427,18 +427,21 @@ static int prefer_mwait_c1_over_halt(con
> > >>
> > >> Hi, this series of patches never seem to have made it as far as the
> > >> mainline kernel, anyone know what needs to happen next?
> > >
> > > My plan is to keep on carrying it locally for as long as I run new
> > > kernels on crusty ole core2 boxen, then stop caring about them entirely
> > > like the rest of the planet :)
> > >
> > 
> > Looks like Ingo Molnar has committed to tip which is probably a good
> > sign, thanks all.
> > (Have to hand this system on to someone who wont be patching kernels...)
> 
> Guys, since I don't have the affected hardware, mind testing the 
> latest sched/core tree:
> 
>   git clone git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git
>   cd tip
>   git checkout sched/core
>   # build a test kernel and boot it
> 
> Or if you already have a kernel git tree, do something like this to 
> pick up the scheduler development tree:
> 
>   cd linux.git
>   git remote add git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git tip
>   git remote update
>   git checkout tip/sched/core
>   # build a test kernel and boot it
> 
> and check whether the mwait related bugs are now fixed for good?

"marge" (Q6600 box) is mostly retired now, but I'll kick her out of her
rocking chair as soon as I can escape from bugzilla.  All should be
well, as she's been running it for ages, and ran it in master just a
couple days ago.

	-Mike

--
To unsubscribe from this list: send the line "unsubscribe linux-pm" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Ian Malone March 18, 2015, 1:55 a.m. UTC | #6
On 17 March 2015 at 08:22, Ingo Molnar <mingo@kernel.org> wrote:
>
> * Ian Malone <ibmalone@gmail.com> wrote:
>

>> Looks like Ingo Molnar has committed to tip which is probably a good
>> sign, thanks all.
>> (Have to hand this system on to someone who wont be patching kernels...)
>
> Guys, since I don't have the affected hardware, mind testing the
> latest sched/core tree:
>
>   git clone git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git
>   cd tip
>   git checkout sched/core
>   # build a test kernel and boot it
>
> Or if you already have a kernel git tree, do something like this to
> pick up the scheduler development tree:
>
>   cd linux.git
>   git remote add git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git tip
>   git remote update
>   git checkout tip/sched/core
>   # build a test kernel and boot it
>
> and check whether the mwait related bugs are now fixed for good?
>

Fixes https://bugzilla.kernel.org/show_bug.cgi?id=60770, thank you.
diff mbox

Patch

--- a/arch/x86/kernel/process.c
+++ b/arch/x86/kernel/process.c
@@ -427,18 +427,21 @@  static int prefer_mwait_c1_over_halt(con
 
 static void mwait_idle(void)
 {
-	if (!need_resched()) {
-		if (this_cpu_has(X86_FEATURE_CLFLUSH_MONITOR))
+	if (!current_set_polling_and_test()) {
+		if (this_cpu_has(X86_FEATURE_CLFLUSH_MONITOR)) {
+			mb();
 			clflush((void *)&current_thread_info()->flags);
+			mb();
+		}
 
 		__monitor((void *)&current_thread_info()->flags, 0, 0);
-		smp_mb();
 		if (!need_resched())
 			__sti_mwait(0, 0);
 		else
 			local_irq_enable();
 	} else
 		local_irq_enable();
+	__current_clr_polling();
 }
 
 void select_idle_routine(const struct cpuinfo_x86 *c)