Carsten Schiers
2009-Jan-07 09:35 UTC
[Xen-devel] AMD P-States not recognized for Xen 3.3 and 3.4
Xen doesn''t seem to fully recognize P-States in my AMD 4050e / Gigabyte M56S-S3 setting. What works is a Xen 3.2-1 Debian with waldi 2.6.18-3.1-2 kernel in a way, that when specifying cpufreq=dom0-kernel and using cpufreq-set, I can change CPU frequency (minor problem here: it will report backwards running clocks as mentioned elsewere here: Timer ISR/0: Time went backwards). But using cpufreq=xen will not report any P-states at all. Tried with different 3.3 versions up to 3.3.1 and 3.4 unstable. With cpuidle and without, also did an update to BIOS F4 (latest version). Used xenpm from 3.3 and 3.4 to check. I attached two dmesg / xm dmesg outputs, V1 will show with cpuidle on F4e BIOS, V2 will show without cpuidle on F4 BIOS. Both used latest Xen 3.4-unstable and waldi 2.6.18-3.3-1 kernel. Any ideas how to proceed? _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Jan Beulich
2009-Jan-07 10:44 UTC
Re: [Xen-devel] AMD P-States not recognized for Xen 3.3 and 3.4
>>> Carsten Schiers <carsten@schiers.de> 07.01.09 10:35 >>> >Xen doesn''t seem to fully recognize P-States in my AMD 4050e / Gigabyte M56S-S3 >setting. > >What works is a Xen 3.2-1 Debian with waldi 2.6.18-3.1-2 kernel in a way, that >when specifying cpufreq=dom0-kernel and using cpufreq-set, I can change CPU >frequency (minor problem here: it will report backwards running clocks as mentioned >elsewere here: Timer ISR/0: Time went backwards). > >But using cpufreq=xen will not report any P-states at all. Tried with different >3.3 versions up to 3.3.1 and 3.4 unstable. With cpuidle and without, also did >an update to BIOS F4 (latest version). Used xenpm from 3.3 and 3.4 to check. > >I attached two dmesg / xm dmesg outputs, V1 will show with cpuidle on F4e BIOS, >V2 will show without cpuidle on F4 BIOS. Both used latest Xen 3.4-unstable and >waldi 2.6.18-3.3-1 kernel. > >Any ideas how to proceed?This is a pre-Fam10 CPU you use - I wondered about the lack of support for P-states there as well a while ago, but was told that it is intentional that there''s no code to handle these. Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Carsten Schiers
2009-Jan-07 10:49 UTC
AW: [Xen-devel] AMD P-States not recognized for Xen 3.3 and 3.4
> ... but was told that it is intentional that there''s no code to handle these.Hm. And for what reason it does work in dom0-kernel? Because it''s done by powernow-k8.ko and userspace software? ----- Originalnachricht ----- Von: Jan Beulich <jbeulich@novell.com> Gesendet: Mit, 7.1.2009 11:44 An: Carsten Schiers <carsten@schiers.de> Cc: xen-devel@lists.xensource.com Betreff: Re: [Xen-devel] AMD P-States not recognized for Xen 3.3 and 3.4>>> Carsten Schiers <carsten@schiers.de> 07.01.09 10:35 >>> >Xen doesn''t seem to fully recognize P-States in my AMD 4050e / Gigabyte M56S-S3 >setting. > >What works is a Xen 3.2-1 Debian with waldi 2.6.18-3.1-2 kernel in a way, that >when specifying cpufreq=dom0-kernel and using cpufreq-set, I can change CPU >frequency (minor problem here: it will report backwards running clocks as mentioned >elsewere here: Timer ISR/0: Time went backwards). > >But using cpufreq=xen will not report any P-states at all. Tried with different >3.3 versions up to 3.3.1 and 3.4 unstable. With cpuidle and without, also did >an update to BIOS F4 (latest version). Used xenpm from 3.3 and 3.4 to check. > >I attached two dmesg / xm dmesg outputs, V1 will show with cpuidle on F4e BIOS, >V2 will show without cpuidle on F4 BIOS. Both used latest Xen 3.4-unstable and >waldi 2.6.18-3.3-1 kernel. > >Any ideas how to proceed?This is a pre-Fam10 CPU you use - I wondered about the lack of support for P-states there as well a while ago, but was told that it is intentional that there''s no code to handle these. Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Jan Beulich
2009-Jan-07 12:37 UTC
Re: AW: [Xen-devel] AMD P-States not recognized for Xen 3.3 and 3.4
>>> Carsten Schiers <carsten@schiers.de> 07.01.09 11:49 >>> >> ... but was told that it is intentional that there''s no code to handle these. > >Hm. And for what reason it does work in dom0-kernel? Because it''s done by >powernow-k8.ko and userspace software?Correct. Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Langsdorf, Mark
2009-Jan-07 20:22 UTC
RE: [Xen-devel] AMD P-States not recognized for Xen 3.3 and 3.4
> > ... but was told that it is intentional that there''s no > code to handle these. > > Hm. And for what reason it does work in dom0-kernel? Because > it''s done by powernow-k8.ko and userspace software?Correct. The family 0xf P-state interface is significantly more complicated than the Family 0x10/architectural P-state interface. Porting it into the Xen hypervisor would possibly introduce some more stability issues. The architectural P-state interface is much stabler and smaller, and it made sense to move it into Xen. Since the family 0xf P-state interface already existed in the Linux kernel, it was easy enough to allow Linux dom0s to use it for RevF systems. Sadly, it''s still got some problems due to the use of TSC as a time source. -Mark Langsdorf Operating System Research Center AMD _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Carsten Schiers
2009-Jan-07 21:02 UTC
AW: RE: [Xen-devel] AMD P-States not recognized for Xen 3.3 and 3.4
So having read that, I have to summarize that working with the Xen 3.2.1 / 2.6.18-xen-3.1-2 kernel / cpufreq=dom0-kernel team seems to be the best option. Only drawback is for sure that typical tools, like powernowd is only using Dom0 load. But I think I could possibly try to modify powernowd or another tool to use what e.g. xentop is producing as output, so that I tune up the system a bit when there is a noticable bigger load than the 10% it is typically sleeping at. Or am I wrong? Thanks, Carsten. -----Ursprüngliche Nachricht----- Von: Langsdorf, Mark [mailto:mark.langsdorf@amd.com] Gesendet: Mittwoch, 7. Januar 2009 21:22 An: Carsten Schiers; xen-devel@lists.xensource.com Betreff: RE: [Xen-devel] AMD P-States not recognized for Xen 3.3 and 3.4> > ... but was told that it is intentional that there''s no > code to handle these. > > Hm. And for what reason it does work in dom0-kernel? Because > it''s done by powernow-k8.ko and userspace software?Correct. The family 0xf P-state interface is significantly more complicated than the Family 0x10/architectural P-state interface. Porting it into the Xen hypervisor would possibly introduce some more stability issues. The architectural P-state interface is much stabler and smaller, and it made sense to move it into Xen. Since the family 0xf P-state interface already existed in the Linux kernel, it was easy enough to allow Linux dom0s to use it for RevF systems. Sadly, it''s still got some problems due to the use of TSC as a time source. -Mark Langsdorf Operating System Research Center AMD _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Carsten Schiers
2009-Jan-07 21:07 UTC
AW: RE: [Xen-devel] AMD P-States not recognized for Xen 3.3 and 3.4
Ah, when you just droped in, Mark: could I safely ignore the TSC error messages or is there any risk included in it... BR, Carsten. -----Ursprüngliche Nachricht----- Von: Carsten Schiers Gesendet: Mittwoch, 7. Januar 2009 22:03 An: jbeulich; mark.langsdorf; xen-devel Betreff: AW: RE: [Xen-devel] AMD P-States not recognized for Xen 3.3 and 3.4 So having read that, I have to summarize that working with the Xen 3.2.1 / 2.6.18-xen-3.1-2 kernel / cpufreq=dom0-kernel team seems to be the best option. Only drawback is for sure that typical tools, like powernowd is only using Dom0 load. But I think I could possibly try to modify powernowd or another tool to use what e.g. xentop is producing as output, so that I tune up the system a bit when there is a noticable bigger load than the 10% it is typically sleeping at. Or am I wrong? Thanks, Carsten. -----Ursprüngliche Nachricht----- Von: Langsdorf, Mark [mailto:mark.langsdorf@amd.com] Gesendet: Mittwoch, 7. Januar 2009 21:22 An: Carsten Schiers; xen-devel@lists.xensource.com Betreff: RE: [Xen-devel] AMD P-States not recognized for Xen 3.3 and 3.4> > ... but was told that it is intentional that there''s no > code to handle these. > > Hm. And for what reason it does work in dom0-kernel? Because > it''s done by powernow-k8.ko and userspace software?Correct. The family 0xf P-state interface is significantly more complicated than the Family 0x10/architectural P-state interface. Porting it into the Xen hypervisor would possibly introduce some more stability issues. The architectural P-state interface is much stabler and smaller, and it made sense to move it into Xen. Since the family 0xf P-state interface already existed in the Linux kernel, it was easy enough to allow Linux dom0s to use it for RevF systems. Sadly, it''s still got some problems due to the use of TSC as a time source. -Mark Langsdorf Operating System Research Center AMD _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Niraj Tolia
2009-Jan-07 21:53 UTC
Re: RE: [Xen-devel] AMD P-States not recognized for Xen 3.3 and 3.4
On Wed, Jan 7, 2009 at 1:02 PM, Carsten Schiers <carsten@schiers.de> wrote:> So having read that, I have to summarize that working with the > Xen 3.2.1 / 2.6.18-xen-3.1-2 kernel / cpufreq=dom0-kernel team > seems to be the best option. > > Only drawback is for sure that typical tools, like powernowd is > only using Dom0 load. But I think I could possibly try to modify > powernowd or another tool to use what e.g. xentop is producing > as output, so that I tune up the system a bit when there is a > noticable bigger load than the 10% it is typically sleeping at. >If you are using the in-kernel ondemand governor (cpufreq=dom0-kernel), it will look at complete system load and not just dom0. Look at cpufreq_ondemand.c in the 2.6.18-xen.hg tree for more info. Cheers, Niraj> > Or am I wrong? > > Thanks, > Carsten. > > -----Ursprüngliche Nachricht----- > Von: Langsdorf, Mark [mailto:mark.langsdorf@amd.com] > Gesendet: Mittwoch, 7. Januar 2009 21:22 > An: Carsten Schiers; xen-devel@lists.xensource.com > Betreff: RE: [Xen-devel] AMD P-States not recognized for Xen 3.3 and 3.4 > > > > ... but was told that it is intentional that there''s no > > code to handle these. > > > > Hm. And for what reason it does work in dom0-kernel? Because > > it''s done by powernow-k8.ko and userspace software? > > Correct. The family 0xf P-state interface is significantly > more complicated than the Family 0x10/architectural P-state > interface. Porting it into the Xen hypervisor would possibly > introduce some more stability issues. The architectural > P-state interface is much stabler and smaller, and it made > sense to move it into Xen. > > Since the family 0xf P-state interface already existed in the > Linux kernel, it was easy enough to allow Linux dom0s to use > it for RevF systems. Sadly, it''s still got some problems > due to the use of TSC as a time source. > > -Mark Langsdorf > Operating System Research Center > AMD > > > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel >-- Niraj Tolia, Researcher, HP Labs http://www.hpl.hp.com/personal/Niraj_Tolia/ _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel