VMware and ACPI

VMware and ACPI

[Jan Rychter]

Hmm... just wondering: what happened to the VMware/ACPI interaction
issues that some people were reporting here?

There were some discussions and it seemed that ACPI idling the processor
while VMware really wanted to use it was the cuplrit. Any resulting
changes?

I'm running 2.4.22-pre10 now and my WindowsXP inside VMware runs
horribly slow. It gets considerably better if I leave an USB device
plugged in (which causes ACPI to use C2 only and never go into C3), but
it still isn't full speed.

--J.


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: VMware and ACPI

[Frank Mehnert]

[-- Attachment #1: Type: text/plain, Size: 1133 bytes --]

On Monday 15 September 2003 23:51, Jan Rychter wrote:
> Hmm... just wondering: what happened to the VMware/ACPI interaction
> issues that some people were reporting here?
>
> There were some discussions and it seemed that ACPI idling the processor
> while VMware really wanted to use it was the cuplrit. Any resulting
> changes?
>
> I'm running 2.4.22-pre10 now and my WindowsXP inside VMware runs
> horribly slow. It gets considerably better if I leave an USB device
> plugged in (which causes ACPI to use C2 only and never go into C3), but
> it still isn't full speed.

Yes, there is still a problem. I use the appending patch since ages. Before
starting VMware, I do

  echo -n "0" > /proc/acpi/processor/CPU/power

and after VMware has terminated I do

  echo -n "1" > /proc/acpi/processor/CPU/power

This prevents ACPI from going into C2 while VMware is active. This solves
at least my problems (slow, bad response) with Windows NT on VMware. I'm
using Linux-2.4.22.

Frank
-- 
## Dept. of Computer Science, Dresden University of Technology, Germany ##
## http://os.inf.tu-dresden.de/~fm3                                     ##

[-- Attachment #2: acpi_no_idle.diff --]
[-- Type: text/x-diff, Size: 1220 bytes --]

--- linux-2.4.22.orig/drivers/acpi/processor.c	Mon Aug 25 13:44:41 2003
+++ linux-2.4.22/drivers/acpi/processor.c	Tue Sep  9 22:31:39 2003
@@ -1677,6 +1677,37 @@
 
 
 static int
+acpi_processor_write_power (
+        struct file		*file,
+        const char		*buffer,
+        unsigned long		count,
+        void			*data)
+{
+	struct acpi_processor	*pr = (struct acpi_processor *) data;
+	char			state_string[2] = {'\0'};
+
+	if (!pr || (count > sizeof(state_string) - 1))
+		return_VALUE(-EINVAL);
+	
+	if (copy_from_user(state_string, buffer, count))
+		return_VALUE(-EFAULT);
+	
+	state_string[count] = '\0';
+
+	if (state_string[0] == '1') {
+	    printk(KERN_INFO PREFIX "enabling acpi idle\n");
+	    pm_idle = acpi_processor_idle;
+	} else {
+	    printk(KERN_INFO PREFIX "disabling acpi idle\n");
+	    pm_idle = pm_idle_save;
+	    acpi_processor_power_activate(pr, ACPI_STATE_C1);
+	}
+
+	return_VALUE(count);
+}
+
+
+static int
 acpi_processor_read_performance (
 	char			*page,
 	char			**start,
@@ -1982,6 +2013,7 @@
 			ACPI_PROCESSOR_FILE_POWER));
 	else {
 		entry->read_proc = acpi_processor_read_power;
+		entry->write_proc = acpi_processor_write_power;
 		entry->data = acpi_driver_data(device);
 	}
 

Re: VMware and ACPI

[Jan Rychter]

[-- Attachment #1: Type: text/plain, Size: 1193 bytes --]

>>>>> "Frank" == Frank Mehnert <fm3-IG//nw+yl+iQIjdd1DhZXWfrygkm6VTR@public.gmane.org> writes:
 Frank> On Monday 15 September 2003 23:51, Jan Rychter wrote:
 >> Hmm... just wondering: what happened to the VMware/ACPI interaction
 >> issues that some people were reporting here?
 >>
 >> There were some discussions and it seemed that ACPI idling the
 >> processor while VMware really wanted to use it was the cuplrit. Any
 >> resulting changes?
 >>
 >> I'm running 2.4.22-pre10 now and my WindowsXP inside VMware runs
 >> horribly slow. It gets considerably better if I leave an USB device
 >> plugged in (which causes ACPI to use C2 only and never go into C3),
 >> but it still isn't full speed.

 Frank> Yes, there is still a problem. I use the appending patch since
 Frank> ages. Before starting VMware, I do

 Frank> echo -n "0" > /proc/acpi/processor/CPU/power
[...]

Thanks. I'll apply this patch.

Is there any chance that this kind of patch could make it into the
mainline? It is really needed for some of us (everybody running VMware,
for one).

BTW, if I do the above echo to a "standard" ACPI (2.4.22), my shell
segfaults. This is probably a bug.

--J.

[-- Attachment #2: Type: application/pgp-signature, Size: 188 bytes --]

Re: VMware and ACPI

[Jan Rychter]

[-- Attachment #1.1: Type: text/plain, Size: 1388 bytes --]

>>>>> "Jan" == Jan Rychter <jan-JAsPCFd0eodBDgjK7y7TUQ@public.gmane.org> writes:
>>>>> "Frank" == Frank Mehnert <fm3-IG//nw+yl+iQIjdd1DhZXWfrygkm6VTR@public.gmane.org> writes:
 Frank> On Monday 15 September 2003 23:51, Jan Rychter wrote:
 > Hmm... just wondering: what happened to the VMware/ACPI interaction
 > issues that some people were reporting here?
 >
 > There were some discussions and it seemed that ACPI idling the
 > processor while VMware really wanted to use it was the cuplrit. Any
 > resulting changes?
 >
 > I'm running 2.4.22-pre10 now and my WindowsXP inside VMware runs
 > horribly slow. It gets considerably better if I leave an USB device
 > plugged in (which causes ACPI to use C2 only and never go into C3),
 > but it still isn't full speed.

 Frank> Yes, there is still a problem. I use the appending patch since
 Frank> ages. Before starting VMware, I do

 Frank> echo -n "0" > /proc/acpi/processor/CPU/power
 Jan> [...]

 Jan> Thanks. I'll apply this patch.

 Jan> Is there any chance that this kind of patch could make it into the
 Jan> mainline? It is really needed for some of us (everybody running
 Jan> VMware, for one).

Here is the patch slightly fixed for the ACPI in 2.4.22 (the old one did
not compile).

Could we please make it go in as a temporary workaround, so that people
can actually use VMware on Linux?

--J.

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1.2: acpi_no_idle.diff --]
[-- Type: text/x-patch, Size: 1322 bytes --]

--- drivers/acpi/processor.c.orig	2003-09-18 20:31:59.000000000 -0700
+++ drivers/acpi/processor.c	2003-09-18 20:48:51.000000000 -0700
@@ -1677,6 +1677,39 @@
 
 
 static int
+acpi_processor_write_power (
+        struct file  *file,
+        const char  *buffer,
+        unsigned long  count,
+        void   *data)
+{
+ struct acpi_processor *pr = (struct acpi_processor *) data;
+ char   state_string[2] = {'\0'};
+	
+ ACPI_FUNCTION_TRACE("acpi_processor_write_power");
+
+ if (!pr || (count > sizeof(state_string) - 1))
+  return_VALUE(-EINVAL);
+ 
+ if (copy_from_user(state_string, buffer, count))
+  return_VALUE(-EFAULT);
+ 
+ state_string[count] = '\0';
+
+ if (state_string[0] == '1') {
+     printk(KERN_INFO PREFIX "enabling acpi idle\n");
+     pm_idle = acpi_processor_idle;
+ } else {
+     printk(KERN_INFO PREFIX "disabling acpi idle\n");
+     pm_idle = pm_idle_save;
+     acpi_processor_power_activate(pr, ACPI_STATE_C1);
+ }
+
+ return_VALUE(count);
+}
+
+
+static int
 acpi_processor_read_performance (
 	char			*page,
 	char			**start,
@@ -1982,6 +2015,7 @@
 			ACPI_PROCESSOR_FILE_POWER));
 	else {
 		entry->read_proc = acpi_processor_read_power;
+		entry->write_proc = acpi_processor_write_power;
 		entry->data = acpi_driver_data(device);
 	}
 

[-- Attachment #2: Type: application/pgp-signature, Size: 188 bytes --]

Re: VMware and ACPI

[Pavel Machek]

Hi!

> Hmm... just wondering: what happened to the VMware/ACPI interaction
> issues that some people were reporting here?
> 
> There were some discussions and it seemed that ACPI idling the processor
> while VMware really wanted to use it was the cuplrit. Any resulting
> changes?
> 
> I'm running 2.4.22-pre10 now and my WindowsXP inside VMware runs
> horribly slow. It gets considerably better if I leave an USB device
> plugged in (which causes ACPI to use C2 only and never go into C3), but
> it still isn't full speed.

What about something like 

nice -n 19 while1

?

-- 
When do you have a heart between your knees?
[Johanka's followup: and *two* hearts?]


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: VMware and ACPI

[Jan Rychter]

[-- Attachment #1.1: Type: text/plain, Size: 1210 bytes --]

>>>>> "Pavel" == Pavel Machek <pavel-+ZI9xUNit7I@public.gmane.org> writes:
 >> Hmm... just wondering: what happened to the VMware/ACPI interaction
 >> issues that some people were reporting here?
 >>
 >> There were some discussions and it seemed that ACPI idling the
 >> processor while VMware really wanted to use it was the cuplrit. Any
 >> resulting changes?
 >>
 >> I'm running 2.4.22-pre10 now and my WindowsXP inside VMware runs
 >> horribly slow. It gets considerably better if I leave an USB device
 >> plugged in (which causes ACPI to use C2 only and never go into C3),
 >> but it still isn't full speed.

 Pavel> What about something like

 Pavel> nice -n 19 while1

"something like" this doesn't do the job nearly as well, because:

  1) performance is better than with an otherwise idle machine, but
     not as good as with the C-state handling turned off

  2) it eats more power, keeping the cpu in C1 is not the same as
     keeping it busy

Please, can we have the patch (attached here again, for everyone's
convenience) applied? It doesn't do anything harmful to people that do
not use it, it just gives us the option of actually running VMware on
Linux.

--J.

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1.2: acpi_no_idle.diff --]
[-- Type: text/x-patch, Size: 1322 bytes --]

--- drivers/acpi/processor.c.orig	2003-09-18 20:31:59.000000000 -0700
+++ drivers/acpi/processor.c	2003-09-18 20:48:51.000000000 -0700
@@ -1677,6 +1677,39 @@
 
 
 static int
+acpi_processor_write_power (
+        struct file  *file,
+        const char  *buffer,
+        unsigned long  count,
+        void   *data)
+{
+ struct acpi_processor *pr = (struct acpi_processor *) data;
+ char   state_string[2] = {'\0'};
+	
+ ACPI_FUNCTION_TRACE("acpi_processor_write_power");
+
+ if (!pr || (count > sizeof(state_string) - 1))
+  return_VALUE(-EINVAL);
+ 
+ if (copy_from_user(state_string, buffer, count))
+  return_VALUE(-EFAULT);
+ 
+ state_string[count] = '\0';
+
+ if (state_string[0] == '1') {
+     printk(KERN_INFO PREFIX "enabling acpi idle\n");
+     pm_idle = acpi_processor_idle;
+ } else {
+     printk(KERN_INFO PREFIX "disabling acpi idle\n");
+     pm_idle = pm_idle_save;
+     acpi_processor_power_activate(pr, ACPI_STATE_C1);
+ }
+
+ return_VALUE(count);
+}
+
+
+static int
 acpi_processor_read_performance (
 	char			*page,
 	char			**start,
@@ -1982,6 +2015,7 @@
 			ACPI_PROCESSOR_FILE_POWER));
 	else {
 		entry->read_proc = acpi_processor_read_power;
+		entry->write_proc = acpi_processor_write_power;
 		entry->data = acpi_driver_data(device);
 	}
 

[-- Attachment #2: Type: application/pgp-signature, Size: 188 bytes --]

Re: Re: VMware and ACPI

[Pavel Machek]

Hi!

>  >> There were some discussions and it seemed that ACPI idling the
>  >> processor while VMware really wanted to use it was the cuplrit. Any
>  >> resulting changes?
>  >>
>  >> I'm running 2.4.22-pre10 now and my WindowsXP inside VMware runs
>  >> horribly slow. It gets considerably better if I leave an USB device
>  >> plugged in (which causes ACPI to use C2 only and never go into C3),
>  >> but it still isn't full speed.
> 
>  Pavel> What about something like
> 
>  Pavel> nice -n 19 while1
> 
> "something like" this doesn't do the job nearly as well, because:
> 
>   1) performance is better than with an otherwise idle machine, but
>      not as good as with the C-state handling turned off
> 
>   2) it eats more power, keeping the cpu in C1 is not the same as
>      keeping it busy
> 
> Please, can we have the patch (attached here again, for everyone's
> convenience) applied? It doesn't do anything harmful to people that do

Looks sane to me. Possible refinement would be saying
"max Cx state you are allowed to use"; one some
machines C3 is usable but is marked bad by bios, it
could be reenabled by this.

-- 
				Pavel
Written on sharp zaurus, because my Velo1 broke. If you have Velo you don't need...



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf