All of lore.kernel.org
 help / color / mirror / Atom feed
* AW: RE: AMD P-States not recognized for Xen 3.3 and 3.4
@ 2009-01-08 10:08 Carsten Schiers
  0 siblings, 0 replies; 4+ messages in thread
From: Carsten Schiers @ 2009-01-08 10:08 UTC (permalink / raw)
  To: Niraj Tolia; +Cc: xen-devel

Oh, thanks, Niraj. 

I overlooked this initially, because this code is not implemented in waldi 3.1-2
kernel, but only in 3.3-1. I'll check it out tonight, as booting a new kernel 
per remote is a bit too dangerous.

This would be exactly what I need.

BR,
Carsten.

Von: Niraj Tolia 
Gesendet: Mit, 7.1.2009 22:53
An: Carsten Schiers 
Cc: jbeulich  ; mark.langsdorf  ; xen-devel 
Betreff: 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  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/

^ permalink raw reply	[flat|nested] 4+ messages in thread
* AW: RE: AMD P-States not recognized for Xen 3.3 and 3.4
@ 2009-01-08 14:53 Carsten Schiers
  0 siblings, 0 replies; 4+ messages in thread
From: Carsten Schiers @ 2009-01-08 14:53 UTC (permalink / raw)
  To: Niraj Tolia, mark.langsdorf, xen-devel

OK, I have found the change and ported it into the 2.6.18-xen-3.1-2
waldi kernel. Fortunately, the Debian Xen 3.2.1 Hypervisor from Lenny,
which is used by my dsitribution (c't-Server), already implements the
xenpf_cpuidletime hypercall #53, which is needed. Some changes here 
and there where necessary, too.

Now, when setting the ondemand govenor, the system behaves as expected.

Still (as with userspace govenors), there are 

  - powernow-k8: error - out of sync, fix 0xd 0x2, vid 0xe 0x16
  - Timer ISR/0: Time went backwards: delta=

messages, when the p-states are changed. 4050e, as already mentioned,
dual-core, single socket.

Can I safely ignore them or do I have to take care somewhere...?

BR,
Carsten.

Von: Niraj Tolia 
Gesendet: Mit, 7.1.2009 22:53
An: Carsten Schiers 
Cc: jbeulich  ; mark.langsdorf  ; xen-devel 
Betreff: 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  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/

^ permalink raw reply	[flat|nested] 4+ messages in thread
* RE: AMD P-States not recognized for Xen 3.3 and  3.4
@ 2009-01-07 20:22 Langsdorf, Mark
  2009-01-07 21:02 ` AW: " Carsten Schiers
  0 siblings, 1 reply; 4+ messages in thread
From: Langsdorf, Mark @ 2009-01-07 20:22 UTC (permalink / raw)
  To: Carsten Schiers, xen-devel

> > ... 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

^ permalink raw reply	[flat|nested] 4+ messages in thread
end of thread, other threads:[~2009-01-08 14:53 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2009-01-08 10:08 AW: RE: AMD P-States not recognized for Xen 3.3 and 3.4 Carsten Schiers
  -- strict thread matches above, loose matches on Subject: below --
2009-01-08 14:53 Carsten Schiers
2009-01-07 20:22 Langsdorf, Mark
2009-01-07 21:02 ` AW: " Carsten Schiers
2009-01-07 21:07   ` Carsten Schiers

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.