Re: [Powertop] [PATCH 2/4] Make the "which C state line" logic better
Rajagopal Venkat <rajagopal.venkat at linaro.org> Mon, 06 Aug 2012 18:58:43 +0530
| Newsgroups | dev.linux.lists.powertop |
|---|---|
| Message-ID | <CA+Z25wXVuuj9Q+VmJLqLPtkrNSddeyiSpv75qxpOhrX+Gyam8Q@mail.gmail.com> |
On 6 August 2012 18:52, Arjan van de Ven <arjan(a)linux.intel.com> wrote: > On 8/6/2012 12:19 AM, Rajagopal Venkat wrote: > > > > On 5 August 2012 22:43, Arjan van de Ven <arjan(a)linux.intel.com <mailto: > arjan(a)linux.intel.com>> wrote: > > > > From 2e88a61859db0592707d1a0a35e33408a0327951 Mon Sep 17 00:00:00 > 2001 > > From: Arjan van de Ven <arjan(a)linux.intel.com <mailto: > arjan(a)linux.intel.com>> > > Date: Sun, 5 Aug 2012 09:57:49 -0700 > > Subject: [PATCH 2/4] Make the "which C state line" logic better > > > > the ARM guys complained that their human-readable C state names > didn't have > > numbers in them, and that as a result, the output is all messed up. > > Using the "linux_name" instead is only a partial solution; it messes > up the x86 > > side of the logic. > > > > > > I fail to understand how using "linux_name" for parsing C states would > mess up > > x86 logic. Each supported C state will have corresponding 'stateX' > directory > > (linux_name) which contain numbers in them. Also there are few hard coded > > states in intel_cpus.cpp file, in which linux_name contains numbers in > them > > as well. In both the cases linux_name contains numbers and hence safe to > > parse. Please let me know if I am missing something here. > > it contains numbers, but not the right ones > so on x86, the package, core and cpu states do not line up properly if I > only use linux_name. > (e.g. package C6 and core C6 are on a different line than CPU C6) > with this patch that is kept correctly, while hopefully also fixing your > issue. > > Ok. Thanks for the clarification. Yes, this patch fixes my problem as well. -- Regards, Rajagopal
attachment.html
(text/html, 2.3 KB)
<br><br><div class="gmail_quote">On 6 August 2012 18:52, Arjan van de Ven <span dir="ltr"><<a href="mailto:[email protected]" target="_blank">[email protected]</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> On 8/6/2012 12:19 AM, Rajagopal Venkat wrote:<br> <div class="im">><br> > On 5 August 2012 22:43, Arjan van de Ven <<a href="mailto:[email protected]">[email protected]</a> <mailto:<a href="mailto:[email protected]">[email protected]</a>>> wrote:<br> ><br> > From 2e88a61859db0592707d1a0a35e33408a0327951 Mon Sep 17 00:00:00 2001<br> </div>> From: Arjan van de Ven <<a href="mailto:[email protected]">[email protected]</a> <mailto:<a href="mailto:[email protected]">[email protected]</a>>><br> <div class="im">> Date: Sun, 5 Aug 2012 09:57:49 -0700<br> > Subject: [PATCH 2/4] Make the "which C state line" logic better<br> ><br> > the ARM guys complained that their human-readable C state names didn't have<br> > numbers in them, and that as a result, the output is all messed up.<br> > Using the "linux_name" instead is only a partial solution; it messes up the x86<br> > side of the logic.<br> ><br> ><br> > I fail to understand how using "linux_name" for parsing C states would mess up<br> > x86 logic. Each supported C state will have corresponding 'stateX' directory<br> > (linux_name) which contain numbers in them. Also there are few hard coded<br> > states in intel_cpus.cpp file, in which linux_name contains numbers in them<br> > as well. In both the cases linux_name contains numbers and hence safe to<br> > parse. Please let me know if I am missing something here.<br> <br> </div>it contains numbers, but not the right ones<br> so on x86, the package, core and cpu states do not line up properly if I only use linux_name.<br> (e.g. package C6 and core C6 are on a different line than CPU C6)<br> with this patch that is kept correctly, while hopefully also fixing your issue.<br> <br></blockquote><div><br>Ok. Thanks for the clarification. Yes, this patch fixes my problem as well.<br><br></div></div>-- <br>Regards,<br>Rajagopal<br><br>