2.4.18-pre7 slow ... apm problem

2.4.18-pre7 slow ... apm problem

[Jeff Chua]

Found the problem.

After disabling CONFIG_APM_CPU_IDLE, the system works fast again.

With pre6 or earlier versions, system works fine though even with
CONFIG_APM_CPU_IDLE enabled.

System is IBM X22 800MHz notebook, 640MB ram.

Thanks,
Jeff
[ jchua@fedex.com ]

---------- Forwarded message ----------
Date: Sun, 27 Jan 2002 14:49:06 +0800 (SGT)
From: Jeff Chua <jeffchua@silk.corp.fedex.com>
To: Linux Kernel <linux-kernel@vger.kernel.org>
Subject: 2.4.18-pre7 slow



1) keyboard rate is a bit slow on 2.4.18-pre7 compared to 2.4.18-pre6.

2) On vmware 3.0, ping localhost is very slow. 2.4.18-pre6 has not such
problem.


Thanks,
Jeff
[ jchua@fedex.com ]

Re: 2.4.18-pre7 slow ... apm problem

[Thomas Hood]

> 1) keyboard rate is a bit slow on 2.4.18-pre7 compared to
>    2.4.18-pre6.
> 2) On vmware 3.0, ping localhost is very slow. 2.4.18-pre6
>    has not such problem.
>
> After disabling CONFIG_APM_CPU_IDLE, the system works fast again.
> With pre6 or earlier versions, system works fine though even with
> CONFIG_APM_CPU_IDLE enabled.

Idle handling in the apm driver was modified in 2.4.18-pre7 .
Back to the drawing board ...

Note that you can disable apm idle handling by setting the
apm idle_threshold parameter to 100.  You don't need to
recompile the kernel.

Re: 2.4.18-pre7 slow ... apm problem

[Alan Cox]

> > 1) keyboard rate is a bit slow on 2.4.18-pre7 compared to
> >    2.4.18-pre6.
> > 2) On vmware 3.0, ping localhost is very slow. 2.4.18-pre6
> >    has not such problem.
> >
> > After disabling CONFIG_APM_CPU_IDLE, the system works fast again.
> > With pre6 or earlier versions, system works fine though even with
> > CONFIG_APM_CPU_IDLE enabled.
> 
> Idle handling in the apm driver was modified in 2.4.18-pre7 .
> Back to the drawing board ...

The keyboard rate one is curious. The vmware one I can easily believe is
caused by Vmware switching in/out of OS's without managing the APM
state of the processor (and leaving it in powersave)

Not sure its drawing board time, just a little investigation.

Alan

Re: 2.4.18-pre7 slow ... apm problem

[Thomas Hood]

> The keyboard rate one is curious. The vmware one I can easily
> believe is caused by Vmware switching in/out of OS's without
> managing the APM state of the processor (and leaving it in
> powersave)

APM idling is done if apm_cpu_idle() is called, and then if
    DELTA(current->times.tms_stime)
    -------------------------------
    DELTA(jiffies)
is greater than the idle threshold of 0.95.  Could that ratio be
affected by VMware?  If so, how?

--
Thomas

Re: 2.4.18-pre7 slow ... apm problem

[Thomas Hood]

I wrote:
> APM idling is done if apm_cpu_idle() is called, and then if
>     DELTA(current->times.tms_stime)
>     -------------------------------
>     DELTA(jiffies)
> is greater than the idle threshold of 0.95.  Could that ratio be
> affected by VMware?  If so, how?

Herm ... I think what you meant was that (a guest OS under)
VMware might be telling the APM BIOS to idle the CPU.
In that case, apm management should be shut off in either
VMware or in the guest OS.

Re: 2.4.18-pre7 slow ... apm problem

[Alan Cox]

> > managing the APM state of the processor (and leaving it in
> > powersave)
> 
> APM idling is done if apm_cpu_idle() is called, and then if
>     DELTA(current->times.tms_stime)
>     -------------------------------
>     DELTA(jiffies)
> is greater than the idle threshold of 0.95.  Could that ratio be
> affected by VMware?  If so, how?

Suppose vmware decides to switch between running Linux and its virtualised
Windows OS. Can it do this during an interrupt - if so what ensures that
vmware isnt switched to after we have done APM idle calls and slowed the
CPU right down ?

If so then I suspect vmware should be issuing APM cpu busy calls itself

Re: 2.4.18-pre7 slow ... apm problem

[Thomas Hood]

On Mon, 2002-01-28 at 05:14, Alan Cox wrote:
> Suppose vmware decides to switch between running Linux and its virtualised
> Windows OS. Can it do this during an interrupt - if so what ensures that
> vmware isnt switched to after we have done APM idle calls and slowed the
> CPU right down ?
> 
> If so then I suspect vmware should be issuing APM cpu busy calls itself

Do you see a difference between VMware and other processes
in their susceptibility to this problem?  If VMware runs
slowly because it gets scheduled in while the CPU is idle
and the apm driver fails to busyize the CPU, won't the same
thing happen for other processes?  If so, then our idle 
handling is fundamentally broken.  If not, then what makes
VMware special?

Re: 2.4.18-pre7 slow ... apm problem

[Stephan von Krawczynski]

On 28 Jan 2002 06:25:05 -0500
Thomas Hood <jdthood@mail.com> wrote:

> On Mon, 2002-01-28 at 05:14, Alan Cox wrote:
> > If so then I suspect vmware should be issuing APM cpu busy calls itself
> 
> Do you see a difference between VMware and other processes
> in their susceptibility to this problem?  If VMware runs
> slowly because it gets scheduled in while the CPU is idle
> and the apm driver fails to busyize the CPU, won't the same
> thing happen for other processes?  If so, then our idle 
> handling is fundamentally broken.  If not, then what makes
> VMware special?

Maybe it's just broken. I have some strange problems with hanging vmware 3
(reproducable) on a SMP machine. On an equal machine vmware 2 runs 
flawlessly. There is no APM or the like involved, both under 2.4.18-pre7.
I just don't trust it.

Regards,
Stephan

Re: 2.4.18-pre7 slow ... apm problem

[Alan Cox]

> > If so then I suspect vmware should be issuing APM cpu busy calls itself
> 
> Do you see a difference between VMware and other processes
> in their susceptibility to this problem?  If VMware runs
> slowly because it gets scheduled in while the CPU is idle
> and the apm driver fails to busyize the CPU, won't the same
> thing happen for other processes?  If so, then our idle 
> handling is fundamentally broken.  If not, then what makes
> VMware special?

We don't know how VMware switches between virtual machines. If that
switch is done behind Linux back, then VMware is effectively special. It
is virtualising the system and it has to virtualise APM status too. If its
doing the switch when it is a current foreground process then it wouldnt
explain the problem

Re: 2.4.18-pre7 slow ... apm problem

[Thomas Hood]

On Mon, 2002-01-28 at 08:18, Alan Cox wrote:
> We don't know how VMware switches between virtual machines. If that
> switch is done behind Linux back, then VMware is effectively special.
> It is virtualising the system and it has to virtualise APM status too.
> If its doing the switch when it is a current foreground process then
> it wouldnt explain the problem

VMware is essentially a hardware emulator, so if the guest OS is
idling the CPU it should only be idling the virtual CPU, not the
real one.  

Having said that, VMware emulates a lot of hardware by making
use of facilities that Linux provides.  It emulates a super-VGA
card by making use of X, for example.  Do you suppose that
VMware emulates CPU slowing by slowing the real CPU?  I hope not.

Since VMware is closed source software we needn't worry our
heads too much about this problem.  VMware users have a 
workaround: set idle_threshold to 100.

Can we get more info about the keyboard repeat rate slowing?

--
Thomas

Re: 2.4.18-pre7 slow ... apm problem

[Jeff Chua]

On Sun, 27 Jan 2002, Stephan von Krawczynski wrote:

> > 1) keyboard rate is a bit slow on 2.4.18-pre7 compared to 2.4.18-pre6.
> What _exactly_ does this mean? Can you elaborate more on your setup and
> your problem?

Sorry, just got off a long flight from San Diego to Singapore. Anyway,
slow ... means that even without vmware, if I just hit return, the lines
would scroll for about every 10 lines and there'll be a litte pause (<0.3
sec). With pre6, there's no such behavior, and if CONFIG_APM_CPU_IDLE is
not set, the "pause" goes away.

> > 2) On vmware 3.0, ping localhost is very slow. 2.4.18-pre6 has not
> such problem.
> 1) linux with vmware and guest system linux

"host" system is linux. "guest" system is linux (actually, I tried with NT
as well, same problem).

The sympton is when I try to ping the "host" from vmware's "guest" system,
the first response came back to the guest's console. Then if I don't type
anything or don't move the mouse on the guest's console, I won't see any
further response on the guest's linux console. Even with a lot of mouse
movement or pressing the keys, the response is still very slow with "ping".

If I ping from the "host" linux console to the "guest" linux system,
responses came back, and does not hang. I'll double check this last point.
Got to recompile the kernel again.

Jeff

Re: 2.4.18-pre7 slow ... apm problem

[Thomas Hood]

On Mon, 2002-01-28 at 15:11, Jeff Chua wrote:
> Sorry, just got off a long flight from San Diego to Singapore. Anyway,
> slow ... means that even without vmware, if I just hit return, the lines
> would scroll for about every 10 lines and there'll be a litte pause (<0.3
> sec). With pre6, there's no such behavior, and if CONFIG_APM_CPU_IDLE is
> not set, the "pause" goes away.

Suggestion: Try setting the idle_threshold to a higher value,
e.g., 98.  (The default value is 95.)

Question to all: Would it be a good idea to de-idle the CPU
inside interrupt handlers?

> "host" system is linux. "guest" system is linux (actually, I tried with NT
> as well, same problem).
> 
> The sympton is when I try to ping the "host" from vmware's "guest" system,
> the first response came back to the guest's console. Then if I don't type
> anything or don't move the mouse on the guest's console, I won't see any
> further response on the guest's linux console. Even with a lot of mouse
> movement or pressing the keys, the response is still very slow with "ping".

> If I ping from the "host" linux console to the "guest" linux system,
> responses came back, and does not hang. I'll double check this last point.
> Got to recompile the kernel again.

Try disabling APM cpu idling (set apm idle_threshold to 100) in the
_guest_ OS.  (Leave it enabled in the host OS.)  Tell us what happens.

Also try disabling APM cpu idling (set apm idle_threshold to 100) in
the _host_ OS.  (Leave it enabled in the guest OS.)  Tell us what
happens.

I repeat: You do not need to recompile the kernel to enable/disable
APM cpu idle: to disable it simply set idle_threshold to 100.

Re: 2.4.18-pre7 slow ... apm problem

[Thomas Hood]

On Mon, 2002-01-28 at 15:11, Jeff Chua wrote:
> Sorry, just got off a long flight from San Diego to Singapore. Anyway,
> slow ... means that even without vmware, if I just hit return, the lines
> would scroll for about every 10 lines and there'll be a litte pause (<0.3
> sec). With pre6, there's no such behavior, and if CONFIG_APM_CPU_IDLE is
> not set, the "pause" goes away.

Suggestion: Try setting the idle_threshold to a higher value,
e.g., 98.  (The default value is 95.)

Question to all: Would it be a good idea to de-idle the CPU
inside interrupt handlers?

> "host" system is linux. "guest" system is linux (actually, I tried with NT
> as well, same problem).
> 
> The sympton is when I try to ping the "host" from vmware's "guest" system,
> the first response came back to the guest's console. Then if I don't type
> anything or don't move the mouse on the guest's console, I won't see any
> further response on the guest's linux console. Even with a lot of mouse
> movement or pressing the keys, the response is still very slow with "ping".

> If I ping from the "host" linux console to the "guest" linux system,
> responses came back, and does not hang. I'll double check this last point.
> Got to recompile the kernel again.

Try disabling APM cpu idling (set apm idle_threshold to 100) in the
_guest_ OS.  (Leave it enabled in the host OS.)  Tell us what happens.

Also try disabling APM cpu idling (set apm idle_threshold to 100) in
the _host_ OS.  (Leave it enabled in the guest OS.)  Tell us what
happens.

I repeat: You do not need to recompile the kernel to enable/disable
APM cpu idle: to disable it simply set idle_threshold to 100.

Re: 2.4.18-pre7 slow ... apm problem

[Jeff Chua]

On Tue, 29 Jan 2002, Jeff Chua wrote:

> > > 1) keyboard rate is a bit slow on 2.4.18-pre7 compared to 2.4.18-pre6.
> > What _exactly_ does this mean? Can you elaborate more on your setup and
> > your problem?
>
> slow ... means that even without vmware, if I just hit return, the lines
> would scroll for about every 10 lines and there'll be a litte pause (<0.3
> sec). With pre6, there's no such behavior, and if CONFIG_APM_CPU_IDLE is
> not set, the "pause" goes away.

2.0 cps on "guest" linux os just pressing "g". 30 cps on "host" linux os.

>
> > > 2) On vmware 3.0, ping localhost is very slow. 2.4.18-pre6 has not
> > such problem.
> > 1) linux with vmware and guest system linux
>
> "host" system is linux. "guest" system is linux (actually, I tried with NT
> as well, same problem).
>
> If I ping from the "host" linux console to the "guest" linux system,
> responses came back, and does not hang. I'll double check this last point.
> Got to recompile the kernel again.

slow from "guest" os to "host" os.
slow from "guest" os to guest's 127.0.0.1

fast from "host" os to "guest" os.

If I set idle_threshold to 100, problem goes away.

APM is not enabled on "guest" os.

Jeff.

Re: 2.4.18-pre7 slow ... apm problem

[Alan Cox]

> Question to all: Would it be a good idea to de-idle the CPU
> inside interrupt handlers?

If you call APM routines from inside APM routines weirdness occurs - so
the answer is no. I'd say that unless this is shown to be occuring in
non vmware stuff its up to vmware to handle the apm situation right

Re: 2.4.18-pre7 slow ... apm problem

[Stephan von Krawczynski]

>                                                                     
> On Sun, 27 Jan 2002, Stephan von Krawczynski wrote:                 
>                                                                     
> > > 1) keyboard rate is a bit slow on 2.4.18-pre7 compared to       
2.4.18-pre6.                                                          
> > What _exactly_ does this mean? Can you elaborate more on your     
setup and                                                             
> > your problem?                                                     
>                                                                     
> Sorry, just got off a long flight from San Diego to Singapore.      
Anyway,                                                               
> slow ... means that even without vmware, if I just hit return, the  
lines                                                                 
> would scroll for about every 10 lines and there'll be a litte pause 
(<0.3                                                                 
> sec). With pre6, there's no such behavior, and if                   
CONFIG_APM_CPU_IDLE is                                                
> not set, the "pause" goes away.                                     
                                                                      
Ok, I cannot see this one, I have no APM enabled on my boxes. Sorry.  
                                                                      
> > > 2) On vmware 3.0, ping localhost is very slow. 2.4.18-pre6 has  
not                                                                   
> > such problem.                                                     
> > 1) linux with vmware and guest system linux                       
>                                                                     
> "host" system is linux. "guest" system is linux (actually, I tried  
with NT                                                               
> as well, same problem).                                             
>                                                                     
> The sympton is when I try to ping the "host" from vmware's "guest"  
system,                                                               
> the first response came back to the guest's console. Then if I don't
type                                                                  
> anything or don't move the mouse on the guest's console, I won't see
any                                                                   
> further response on the guest's linux console. Even with a lot of   
mouse                                                                 
> movement or pressing the keys, the response is still very slow with 
"ping".                                                               
                                                                      
This is interesting.                                                  
I have not set up a guest linux yet, but I experienced a problem with 
Win98 guest which may sound related:                                  
I start the guest win98 and try to open a dos-window. The window opens
but no output is presented (no prompt, no nothing) and guest system   
somehow "hangs". Sometimes (rarely) I can make it work again by       
hitting keys on the keyboard. The effect started off as window coming 
up with prompt, I tried to ping the host system, and the first packet 
was somehow slow, but then everything was ok. On the next guest boot, 
some output appeared at the dosbox, but the prompt was delayed. Now I 
get no prompt no matter what I try.                                   
Host system is 2.4.18-pre7.                                           
Vmware was installed from scratch, win98 guest was installed from     
scratch with no additions whatsoever.                                 
ping from host to guest works flawlessly.                             
                                                                      
> If I ping from the "host" linux console to the "guest" linux system,
> responses came back, and does not hang. I'll double check this last 
point.                                                                
> Got to recompile the kernel again.                                  
                                                                      
As I never saw this with vmware 2 (even not on 2.4.18-pre7) I would   
say version 3 has a real problem somewhere.                           
                                                                      
Regards,                                                              
Stephan                                                               
                                                                      
                                                                      

Re: 2.4.18-pre7 slow ... apm problem

[Petr Vandrovec]

On 28 Jan 02 at 22:20, Alan Cox wrote:
> > Question to all: Would it be a good idea to de-idle the CPU
> > inside interrupt handlers?
> 
> If you call APM routines from inside APM routines weirdness occurs - so
> the answer is no. I'd say that unless this is shown to be occuring in
> non vmware stuff its up to vmware to handle the apm situation right

Hi,
  unfortunately, majordomo kicked me yesterday evening, so I had to
follow this discussion through web archives, and I have some problems
with understanding why problem happens...

  When vmmon switches out of the Linux to the virtual machine, it disables
all (APIC) NMI sources, disables IRQ on the CPU, completely replaces CPU 
context (GDT/IDT/...) and switches to VMM, which does not physically
access anything except main memory and things emulated inside VMM
(like accesses to VGA/SVGA framebuffers). When an IRQ arrives to virtual
machine, it disables all IRQs, restores Linux kernel contexts, reenables
NMI sources, and restarts IRQ from vmmon by using INT xx instruction. 
And everything this happens in process context (when VMM_RUN ioctl is
invoked).

  So this behavior should be completely transparent to Linux kernel,
it should just see VMware process as a HLT instruction executed in vmmon
module, which delays interrupt confirmation/delivery a bit. Only thing
which could cause troubles is SMI arrival - but SMI handler cannot notice
any difference (except that APIC IRQ sources delivered as a NMI to CPU
are disabled), as paging is turned off during SMI handler, and physical
memory contents is same under both vmware and Linux kernel.

  So I'm really puzzled.
                                                Best regards,
                                                    Petr Vandrovec
                                                    vandrove@vc.cvut.cz
                                                    
P.S.: I'm not trying to say that it is not VMware fault. It probably
is, as I saw same behavior on my old Pentium 120MHz notebook two years
ago - but as problem disappeared as it appeared...

Re: 2.4.18-pre7 slow ... apm problem

[Jeff Chua]

On Mon, 28 Jan 2002, Thomas Hood wrote:

> Suggestion: Try setting the idle_threshold to a higher value,
> e.g., 98.  (The default value is 95.)

With 98, "ping localhost" on "guest" os showed 2 responses, then pause for
few seconds, then response, ...

With 95, I got the 1st response, then nothing. 98 seems better, but still
slow...

With 100, it's perfect.


> Try disabling APM cpu idling (set apm idle_threshold to 100) in the
> _guest_ OS.  (Leave it enabled in the host OS.)  Tell us what happens.

No difference, still slow. Even with guest os running pre6, it's still
slow.

>
> Also try disabling APM cpu idling (set apm idle_threshold to 100) in
> the _host_ OS.  (Leave it enabled in the guest OS.)  Tell us what
> happens.

guest os "ping localhost" is perfect.

> I repeat: You do not need to recompile the kernel to enable/disable
> APM cpu idle: to disable it simply set idle_threshold to 100.

Ok got it. But still have to reboot machine as the apm is loaded and can't
"rmmod apm". Complained that it's in use ([kapmd] even after stopping
apmd.

By the way, setting power_off=1 or realmode_power_off=1 does not power off
the h/w.


Thanks,
Jeff.

Re: 2.4.18-pre7 slow ... apm problem

[Jeff Chua]

On Tue, 29 Jan 2002, Stephan von Krawczynski wrote:

> Ok, I cannot see this one, I have no APM enabled on my boxes. Sorry.

If I set apm idle off, vmware guest os "ping localhost" works fine.

> As I never saw this with vmware 2 (even not on 2.4.18-pre7) I would
> say version 3 has a real problem somewhere.

Never had any problem with vmware3 until pre7.

Try to test vmware2 on pre7 with apm cpu_idle enabled. I think you'll see
the same problem. Again, pre6 with apm cpu_idle enabled works fine.

Jeff

Re: 2.4.18-pre7 slow ... apm problem

[Petr Vandrovec]

On 29 Jan 02 at 20:36, Jeff Chua wrote:
> On Mon, 28 Jan 2002, Thomas Hood wrote:
> 
> > Suggestion: Try setting the idle_threshold to a higher value,
> > e.g., 98.  (The default value is 95.)
> 
> With 98, "ping localhost" on "guest" os showed 2 responses, then pause for
> few seconds, then response, ...
> 
> With 95, I got the 1st response, then nothing. 98 seems better, but still
> slow...
> 
> With 100, it's perfect.

I've got an idea - if you were saying that ping host->guest is fine,
but other way around it does not work. Can you apply 
ftp://platan.vc.cvut.cz/pub/vmware/vmware-ws-1455-update5.tar.gz
to your VMware 3.x? Stock vmware-3.x modules use netif_rx() instead
of netif_rx_ni(), and so network bottom half was not run under some 
conditions.

Patch also allows you to run VMware on 2.5.3-pre5, BTW.
                                                Best regards,
                                                    Petr Vandrovec
                                                    vandrove@vc.cvut.cz
                                                    

Re: 2.4.18-pre7 slow ... apm problem

[Stephan von Krawczynski]

> On 29 Jan 02 at 20:36, Jeff Chua wrote:                             
> > On Mon, 28 Jan 2002, Thomas Hood wrote:                           
> >                                                                   
> > > Suggestion: Try setting the idle_threshold to a higher value,   
> > > e.g., 98.  (The default value is 95.)                           
> >                                                                   
> > With 98, "ping localhost" on "guest" os showed 2 responses, then  
pause for                                                             
> > few seconds, then response, ...                                   
> >                                                                   
> > With 95, I got the 1st response, then nothing. 98 seems better,   
but still                                                             
> > slow...                                                           
> >                                                                   
> > With 100, it's perfect.                                           
>                                                                     
> I've got an idea - if you were saying that ping host->guest is fine,
> but other way around it does not work. Can you apply                
> ftp://platan.vc.cvut.cz/pub/vmware/vmware-ws-1455-update5.tar.gz    
> to your VMware 3.x? Stock vmware-3.x modules use netif_rx() instead 
> of netif_rx_ni(), and so network bottom half was not run under some 
> conditions.                                                         
>                                                                     
> Patch also allows you to run VMware on 2.5.3-pre5, BTW.             
                                                                      
We are completely OT here, but anyway it may be common interest:      
                                                                      
Applying this patch makes some of my problems go. dos-box does no     
longer hang the whole guest system, but succeeds in 4 of 5 runs. If it
does not output anything inside the dos-window and I hit the          
fullscreen (ALT-ENTER) everything is normal, ALT-ENTER again shows the
correct win desktop with dos-box and correct output there.            
It is almost ok, it does not hang, only a minor quirk left.           
                                                                      
Thanks,                                                               
Stephan                                                               
                                                                      
                                                                      

Re: 2.4.18-pre7 slow ... apm problem

[Jeff Chua]

On Tue, 29 Jan 2002, Petr Vandrovec wrote:
> I've got an idea - if you were saying that ping host->guest is fine,
> but other way around it does not work. Can you apply
> ftp://platan.vc.cvut.cz/pub/vmware/vmware-ws-1455-update5.tar.gz
> to your VMware 3.x? Stock vmware-3.x modules use netif_rx() instead
> of netif_rx_ni(), and so network bottom half was not run under some
> conditions.

Applied patch. Still same problem.

On host
	modprobe apm idle_threshold=100, guest ping lo, no problem
	modprobe apm idle_threshold=99,  guest ping lo, slow

Jeff.

Re: 2.4.18-pre7 slow ... apm problem

[Thomas Hood]

On Tue, 2002-01-29 at 07:36, Jeff Chua wrote:
> Ok got it. But still have to reboot machine as the apm is loaded and can't
> "rmmod apm". Complained that it's in use ([kapmd] even after stopping
> apmd.

That's a bug, I think.  You should be able to rmmod the apm module.




_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com

Re: 2.4.18-pre7 slow ... apm problem

[Stephen Rothwell]

Hi Jeff, Greg and other interested parties,

Would you like to try another patch? :-)

This is rather longer than needed, it has some tidy ups from Thomas
Hood as well.  I have basically simplified the idle loop and added
a couple of more points where it can escape.

I am not seeing your problems, but then again I am running on an IBM
Thinkpad, so I do BIOS calls with interrupts enabled and the BIOS halts
on idle (as opposed to slowing the CPU).  I also have SpeedStep
disabled.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

diff -ruN 2.4.18-pre7/arch/i386/kernel/apm.c 2.4.18-pre7-APM.1/arch/i386/kernel/apm.c
--- 2.4.18-pre7/arch/i386/kernel/apm.c	Thu Jan 24 11:33:54 2002
+++ 2.4.18-pre7-APM.1/arch/i386/kernel/apm.c	Tue Jan 29 22:56:09 2002
@@ -380,7 +380,7 @@
 static int			set_pm_idle;
 static int			suspends_pending;
 static int			standbys_pending;
-static int			waiting_for_resume;
+static int			ignore_sys_suspend;
 static int			ignore_normal_resume;
 static int			bounce_interval = DEFAULT_BOUNCE_INTERVAL;
 
@@ -761,15 +761,6 @@
 	}
 }
 
-/*
- * If no process has really been interested in
- * the CPU for some time, we want to call BIOS
- * power management - we probably want
- * to conserve power.
- */
-#define IDLE_CALC_LIMIT   (HZ * 100)
-#define IDLE_LEAKY_MAX    16
-
 static void (*sys_idle)(void);
 
 extern void default_idle(void);
@@ -777,28 +768,24 @@
 /**
  * apm_cpu_idle		-	cpu idling for APM capable Linux
  *
- * This is the idling function the kernel executes when APM is available. It 
- * tries to do BIOS powermanagement based on the average system idle time.
- * Furthermore it calls the system default idle routine.
+ * This is the idling function the kernel executes when APM is available.
+ * It tries to do BIOS power management based on the average system
+ * idle time.  Furthermore it calls the system idle routines.
  */
 
 static void apm_cpu_idle(void)
 {
-	static int use_apm_idle = 0;
-	static unsigned int last_jiffies = 0;
-	static unsigned int last_stime = 0;
-
-	int apm_is_idle = 0;
-	unsigned int jiffies_since_last_check = jiffies - last_jiffies;
-	unsigned int t1;
+	static int use_apm_idle;
+	static unsigned int last_jiffies;
+	static unsigned int last_stime;
 
+	int apm_idle_done = 0;
+	unsigned int jiffies_since_last_check;
+
+	jiffies_since_last_check = jiffies - last_jiffies;
 
 recalc:
-	if (jiffies_since_last_check > IDLE_CALC_LIMIT) {
-		use_apm_idle = 0;
-		last_jiffies = jiffies;
-		last_stime = current->times.tms_stime;
-	} else if (jiffies_since_last_check > idle_period) {
+	if (jiffies_since_last_check > idle_period) {
 		unsigned int idle_percentage;
 
 		idle_percentage = current->times.tms_stime - last_stime;
@@ -809,39 +796,33 @@
 		last_stime = current->times.tms_stime;
 	}
 
-	t1 = IDLE_LEAKY_MAX;
-
 	while (!current->need_resched) {
 		if (use_apm_idle) {
-			unsigned int t;
+			unsigned int t = jiffies;
 
-			t = jiffies;
 			switch (apm_do_idle()) {
-			case 0: apm_is_idle = 1;
-				if (t != jiffies) {
-					if (t1) {
-						t1 = IDLE_LEAKY_MAX;
-						continue;
-					}
-				} else if (t1) {
-					t1--;
+			case 0: apm_idle_done = 1;
+				if (t != jiffies)
 					continue;
-				}
 				break;
-			case 1: apm_is_idle = 1;
+			case 1: apm_idle_done = 1;
 				break;
 			}
 		}
+		if (current->need_resched)
+			break;
 		if (sys_idle)
 			sys_idle();
 		else
 			default_idle();
+		if (current->need_resched)
+			break;
 		jiffies_since_last_check = jiffies - last_jiffies;
 		if (jiffies_since_last_check > idle_period)
 			goto recalc;
 	}
 
-	if (apm_is_idle)
+	if (apm_idle_done)
 		apm_do_busy();
 }
 
@@ -1196,7 +1177,7 @@
 			if (apm_info.connection_version > 0x100)
 				apm_set_power_state(APM_STATE_REJECT);
 			err = -EBUSY;
-			waiting_for_resume = 0;
+			ignore_sys_suspend = 0;
 			printk(KERN_WARNING "apm: suspend was vetoed.\n");
 			goto out;
 		}
@@ -1295,16 +1276,15 @@
 				break;
 			}
 			/*
-			 * If we are already processing a SUSPEND,
-			 * then further SUSPEND events from the BIOS
-			 * will be ignored.  We also return here to
-			 * cope with the fact that the Thinkpads keep
-			 * sending a SUSPEND event until something else
-			 * happens!
+			 * If we are already processing a SUSPEND, then
+			 * further SUSPEND events from the BIOS should
+			 * be ignored.  We have to check for this because
+			 * Thinkpads keep sending SUSPEND events until
+			 * something else happens!
 			 */
-			if (waiting_for_resume)
+			if (ignore_sys_suspend)
 				return;
-			waiting_for_resume = 1;
+			ignore_sys_suspend = 1;
 			queue_event(event, NULL);
 			if (suspends_pending <= 0)
 				(void) suspend(1);
@@ -1313,7 +1293,7 @@
 		case APM_NORMAL_RESUME:
 		case APM_CRITICAL_RESUME:
 		case APM_STANDBY_RESUME:
-			waiting_for_resume = 0;
+			ignore_sys_suspend = 0;
 			last_resume = jiffies;
 			ignore_bounce = 1;
 			if ((event != APM_NORMAL_RESUME)
@@ -1381,7 +1361,7 @@
 		if (exit_kapmd)
 			break;
 		/*
-		 * Ok, check all events, check for idle (and mark us sleeping
+		 * Ok, check all events (and mark us sleeping
 		 * so as not to count towards the load average)..
 		 */
 		set_current_state(TASK_INTERRUPTIBLE);
@@ -1455,6 +1435,11 @@
 	return 0;
 }
 
+/*
+ * Note that the drivers may reject a suspend request.
+ * When this happens, no suspend is done, and the ioctl()
+ * returns the EBUSY error code to the user.
+ */
 static int do_ioctl(struct inode * inode, struct file *filp,
 		    u_int cmd, u_long arg)
 {

Re: 2.4.18-pre7 slow ... apm problem

[Jeff Chua]

On 29 Jan 2002, Thomas Hood wrote:

> On Tue, 2002-01-29 at 07:36, Jeff Chua wrote:
> > Ok got it. But still have to reboot machine as the apm is loaded and can't
> > "rmmod apm". Complained that it's in use ([kapmd] even after stopping
> > apmd.
>
> That's a bug, I think.  You should be able to rmmod the apm module.

found the reason why I can't rmmod apm ... xfree is using it. If I start
Xfree first, then modprobe apm, then I can rmmod apm.

Jeff.

Re: 2.4.18-pre7 slow ... apm problem

[Jeff Chua]

On Wed, 30 Jan 2002, Stephen Rothwell wrote:

> Would you like to try another patch? :-)

sure, will try tonight.

> I am not seeing your problems, but then again I am running on an IBM
> Thinkpad, so I do BIOS calls with interrupts enabled and the BIOS halts
> on idle (as opposed to slowing the CPU).  I also have SpeedStep
> disabled.

I've a ThinkPad X22.

My .config ...

	CONFIG_APM=m
	# CONFIG_APM_IGNORE_USER_SUSPEND is not set
	# CONFIG_APM_DO_ENABLE is not set
	CONFIG_APM_CPU_IDLE=y
	# CONFIG_APM_DISPLAY_BLANK is not set
	# CONFIG_APM_RTC_IS_GMT is not set
	# CONFIG_APM_ALLOW_INTS is not set
	# CONFIG_APM_REAL_MODE_POWER_OFF is not set

/etc/modules.conf
	options apm idle_threshold=95 power_off=1



Jeff

Re: 2.4.18-pre7 slow ... apm problem

[Jeff Chua]

On Wed, 30 Jan 2002, Stephen Rothwell wrote:

> This is rather longer than needed, it has some tidy ups from Thomas
> Hood as well.  I have basically simplified the idle loop and added
> a couple of more points where it can escape.

applied, and tested, same problem still persist. Only way right now is to
set idle_threshold to 100.

Sorry for the late reply.


Jeff.