From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stefan Bader Subject: Re: Workings/effectiveness of the xen-acpi-processor driver Date: Thu, 26 Apr 2012 18:25:28 +0200 Message-ID: <4F9976F8.8040502@canonical.com> References: <4F97F58A.8090409@canonical.com> <20120426155033.GE26830@phenom.dumpdata.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7413593064046783372==" Return-path: In-Reply-To: <20120426155033.GE26830@phenom.dumpdata.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Konrad Rzeszutek Wilk Cc: "xen-devel@lists.xensource.com" , Jan Beulich List-Id: xen-devel@lists.xenproject.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============7413593064046783372== Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="------------enigCEB2AD89CFDA2F503AE61094" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigCEB2AD89CFDA2F503AE61094 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 26.04.2012 17:50, Konrad Rzeszutek Wilk wrote: > On Wed, Apr 25, 2012 at 03:00:58PM +0200, Stefan Bader wrote: >> Since there have been requests about that driver to get backported int= o 3.2, I >> was interested to find out what or how much would be gained by that. >> >> The first system I tried was an AMD based one (8 core Opteron 6128@2GH= z). Which >> was not very successful as the drivers bail out of the init function b= ecause the >> first call to acpi_processor_register_performance() returns -ENODEV. T= here is >> some frequency scaling when running without Xen, so I need to do some = more >> debugging there. >=20 > Did you back-port the other components - the ones that turn off the nat= ive > frequency scalling? >=20 > provide disable_cpufreq() function to disable the API. > xen/acpi-processor: Do not depend on CPU frequency scaling drivers. > xen/cpufreq: Disable the cpu frequency scaling drivers from loadi= ng >> Yes, here is the full set for reference: * xen/cpufreq: Disable the cpu frequency scaling drivers from loading. * xen/acpi: Remove the WARN's as they just create noise. * xen/acpi: Fix Kconfig dependency on CPU_FREQ * xen/acpi-processor: Do not depend on CPU frequency scaling drivers. * xen/acpi-processor: C and P-state driver that uploads said data to hype= r * provide disable_cpufreq() function to disable the API. >> The second system was an Intel one (4 core i7 920@2.67GHz) which was >> successfully loading the driver. Via xenpm I can see the various frequ= encies and >> also see them being changed. However the cpuidle data out of xenpm loo= ks a bit odd: >> >> #> xenpm get-cpuidle-states 0 >> Max C-state: C7 >> >> cpu id : 0 >> total C-states : 2 >> idle time(ms) : 10819311 >> C0 : transition [00000000000000000001] >> residency [00000000000000005398 ms] >> C1 : transition [00000000000000000001] >> residency [00000000000010819311 ms] >> pc3 : [00000000000000000000 ms] >> pc6 : [00000000000000000000 ms] >> pc7 : [00000000000000000000 ms] >> cc3 : [00000000000000000000 ms] >> cc6 : [00000000000000000000 ms] >> >> Also gathering samples over 30s does look like only C0 and C1 are used= =2E This >=20 > Yes.=20 >> might be because C1E support is enabled in BIOS but when looking at th= e >> intel_idle data in sysfs when running without a hypervisor will show C= 3 and C6 >> for the cores. That could have been just a wrong output, so I plugged = in a power >> meter and compared a kernel running natively and running as dom0 (with= and >> without the acpi-processor driver). >> >> Native: 175W >> dom0: 183W (with only marginal difference between with or without th= e >> processor driver) >> [yes, the system has a somewhat high base consumption which I attribut= e to a >> ridiculously dimensioned graphics subsystem to be running a text conso= le] >> >> This I would take as C3 and C6 really not being used and the frequency= scaling >=20 > To go in deeper modes there is also a need to backport a Xen unstable > hypercall which will allow the kernel to detect the other states beside= s > C0-C2. >=20 > "XEN_SET_PDC query was implemented in c/s 23783: > "ACPI: add _PDC input override mechanism". > =20 I see. There is a kernel patch about enabling MWAIT that refers to that..= =2E >=20 >> having no impact on the idle system is not that much surprising. But i= f that was >> true it would also limit the usefulness of the turbo mode which I unde= rstand >> would also be limited by the c-state of the other cores. >=20 > Hm, I should double-check that - but somehow I thought that Xen indepen= detly > checks for TurboMode and if the P-states are in, then they are activate= d. >=20 Turbo mode should be enabled. I had been only looking at a generic overvi= ew about it on Intel site which sounded like it would make more of a differ= ence on how much one core could get overclocked related to how many cores are act= ive (and I translated active or not into deeper c-states or not). Looking at the verbose output of turbostat it seems not to make that much= difference whether 2-4 cores are running. A single core alone could get o= ne more increment in clock stepping. That does not immediately sound a lot. And o= f course how much or long the higher clock is used depends on other factors= as well and is not under OS control. In the end it is probably quite dynamic and hard to come up with hard fac= ts to prove its value. Though if I can lower the idle power usage by reaching a= bit further, that would greatly help to justify the effort and potential risk= of backporting... >> >> Do I misread the data I see? Or maybe its a known limitation? In case = it is >> worth doing more research I'll gladly try things and gather more data.= >=20 > Just missing some patches.=20 >=20 > Oh, and this one: > xen/acpi: Fix Kconfig dependency on CPU_FREQ >=20 > Hmm.. I think a patch disappeared somewhere. >=20 >> >> Thanks, >> Stefan >> >=20 >=20 >=20 > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel --------------enigCEB2AD89CFDA2F503AE61094 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBCgAGBQJPmXb4AAoJEOhnXe7L7s6jmYoP/RgylFM4I1tCCFN+Hm3r2gAg cJ2jAM7ww39Mxhe4Yp3+O6l9cI4GS2i4PY/pdZfnbv6Rfe/3DdVMjpzS11TOtBO3 IbTUzfPYKvtYI6dIds45Vlgbx35NwAyzapPkTZYVmPy3OFL5dCo53M4vtXlx7uiP VXpE7qmaAnJjNeTM/0yMAc9opeZMYVi5sDhTRr7/9XZfEjoJw2ygOGFnWrnunuGA zM15cw38nanccG2YJ/ut8CeK0I0SjXissnwTaAOTC96jJXXNqgleXXYTFHa7aJQQ emvmqjdKADWsRzZMtiyYNI1Wq9oACCauMueSoLeBnFkedtg2Zha7mHT+5ipL9av6 mLyCv9o02g8i8mrB2yajLWvC4Kj5VoBmQvPKqO9DrfFN23Wx+jaLx5buwZgMDc5J S3n/WFYj/Tg3rN1NV/9zKuUTwOsOaZeXyc9mh3W5YY/S32HUIHn8npeBH1vZ9Zbb Ciwaqp11af8cIqp/ntmy7+SWUZbRE/QJa5S3TDrfh8XPFeTdZ+qI9TNxQC2mELQV /jugmoFp6TF7RuVmTr3G5JA+UfYhv57zzGtZNtHRkag3D4n9qtUHm/VxoiEZgnRg LXkgH54lV3yigyJOvYTGrM+Us1aef9kqvSv6dlrMJOd1RWoqV8vFjT8HOmY5EwhY Q1KWQ/fWnBkD+rLdV6mW =MsbZ -----END PGP SIGNATURE----- --------------enigCEB2AD89CFDA2F503AE61094-- --===============7413593064046783372== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============7413593064046783372==--