lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <27240C0AC20F114CBF8149A2696CBE4A01E5B762@SHSMSX101.ccr.corp.intel.com>
Date:	Thu, 14 Aug 2014 14:26:38 +0000
From:	"Liu, Chuansheng" <chuansheng.liu@...el.com>
To:	Daniel Lezcano <daniel.lezcano@...aro.org>,
	Peter Zijlstra <peterz@...radead.org>
CC:	"Rafael J. Wysocki" <rjw@...ysocki.net>,
	"linux-pm@...r.kernel.org" <linux-pm@...r.kernel.org>,
	LKML <linux-kernel@...r.kernel.org>,
	"Liu, Changcheng" <changcheng.liu@...el.com>,
	"Wang, Xiaoming" <xiaoming.wang@...el.com>,
	"Chakravarty, Souvik K" <souvik.k.chakravarty@...el.com>
Subject: RE: [PATCH] cpuidle: Fix the CPU stuck at C0 for 2-3s after PM_QOS
 back to DEFAULT



> -----Original Message-----
> From: Daniel Lezcano [mailto:daniel.lezcano@...aro.org]
> Sent: Thursday, August 14, 2014 10:17 PM
> To: Liu, Chuansheng; Peter Zijlstra
> Cc: Rafael J. Wysocki; linux-pm@...r.kernel.org; LKML; Liu, Changcheng;
> Wang, Xiaoming; Chakravarty, Souvik K
> Subject: Re: [PATCH] cpuidle: Fix the CPU stuck at C0 for 2-3s after PM_QOS
> back to DEFAULT
> 
> On 08/14/2014 04:10 PM, Liu, Chuansheng wrote:
> >
> >
> >> -----Original Message-----
> >> From: Peter Zijlstra [mailto:peterz@...radead.org]
> >> Sent: Thursday, August 14, 2014 9:13 PM
> >> To: Liu, Chuansheng
> >> Cc: Daniel Lezcano; Rafael J. Wysocki; linux-pm@...r.kernel.org; LKML; Liu,
> >> Changcheng; Wang, Xiaoming; Chakravarty, Souvik K
> >> Subject: Re: [PATCH] cpuidle: Fix the CPU stuck at C0 for 2-3s after PM_QOS
> >> back to DEFAULT
> >>
> >> On Thu, Aug 14, 2014 at 11:24:06AM +0000, Liu, Chuansheng wrote:
> >>> If inspecting the polling flag, we can not fix the race between poll_idle and
> >> smp_callback,
> >>> since in poll_idle(), before set polling flag, if the smp_callback come in, then
> >> no resched bit set,
> >>> after that, poll_idle() will do the polling action, without reselection
> >> immediately, it will bring power
> >>> regression here.
> >>
> >> -ENOPARSE. Is there a question there?
> >
> > Lezcano suggest to inspect the polling flag, then code is like below:
> > smp_callback() {
> > if (polling_flag)
> >    set_resched_bit;
> > }
> >
> > And the poll_idle code is like below:
> > static int poll_idle(struct cpuidle_device *dev,
> >                  struct cpuidle_driver *drv, int index)
> > {
> >          local_irq_enable();
> >          if (!current_set_polling_and_test()) {
> >                  while (!need_resched())
> 
> Or alternatively, something like:
> 
> 	while (!need_resched() || kickme) {
> 		...
> 	}
> 
> 
> smp_callback()
> {
> 	kickme = 1;
> }
> 
> kickme is a percpu variable and set to zero when exiting the 'enter'
> callback.
> 
> So we don't mess with the polling flag, which is already a bit tricky.
> 
> This patch is very straightforward to illustrate the idea.
> 
> >                          cpu_relax();
> >          }
> >          current_clr_polling();
> >
> >          return index;
> > }
> >
Thanks Lezcano, the new flag kickme sounds making things simple,
will try to send one new patch to review:)



Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ