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
| ||
|
Date: Tue, 18 Mar 2014 12:25:14 -0700 From: Dirk Brandewie <dirk.brandewie@...il.com> To: "Srivatsa S. Bhat" <srivatsa.bhat@...ux.vnet.ibm.com> CC: dirk.brandewie@...il.com, linux-pm@...r.kernel.org, linux-kernel@...r.kernel.org, rjw@...ysocki.net, patrick.marlier@...il.com, viresh.kumar@...aro.org, Dirk Brandewie <dirk.j.brandewie@...el.com> Subject: Re: [PATCH v3 0/2] Add stop callback to the cpufreq_driver interface. On 03/18/2014 12:08 PM, Srivatsa S. Bhat wrote: > On 03/18/2014 10:52 PM, dirk.brandewie@...il.com wrote: >> From: Dirk Brandewie <dirk.j.brandewie@...el.com> >> > > I don't mean to nitpick, but generally its easier to deal with > patchsets if you post the subsequent versions in fresh email threads. > Otherwise it can get a bit muddled along with too many other email > discussions in the same thread :-( > >> Changes: >> v2->v3 >> Changed the calling of the ->stop() callback to be conditional on the >> core being the last core controlled by a given policy. >> > > Wait, why? I'm sorry if I am not catching up with the discussions on > this issue quickly enough, but I don't see why we should make it > conditional on _that_. I thought we agreed that we should make it > conditional in the sense that ->stop() should be invoked only for > ->setpolicy drivers, right? This was done at Viresh's suggestion since thought there might be value for ->target drivers. Any of the options work for me called only for set_policy scaling drivers called unconditionally for all scaling drivers called for last core controlled by a given policy > > The way I look at it, ->stop() gives you a chance to stop managing > the CPU going offline. As in "stop this CPU". ->exit() is your chance > to cleanup the policy, since all its users have gone offline (or this > is the last CPU belonging to that policy which is going offline). > > With this in mind, we should invoke ->stop() every time we take a > CPU offline, and invoke ->exit() only when the last CPU in the policy > goes offline. This is exactly what will happen for intel_pstate since the policies cover a single core. I will defer to you and Viresh how policies that affect more that one cpu should be handled. What intel_pstate needs it to be called during the PREPARE phase of the offline process. > > What am I missing? > > Regards, > Srivatsa S. Bhat > -- 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