Bug 101467

Summary: Polling /proc/acpi/*/state chews up 10-15% of the processor
Product: [Retired] Red Hat Linux Beta Reporter: John Beimler <john>
Component: kernelAssignee: Arjan van de Ven <arjanv>
Status: CLOSED UPSTREAM QA Contact: Brian Brock <bbrock>
Severity: medium Docs Contact:
Priority: medium    
Version: beta1CC: acpi-bugzilla, p.van.egdom, riel
Target Milestone: ---   
Target Release: ---   
Hardware: i386   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2004-03-25 00:39:01 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
dmesg from the system
none
acpidmp from the system none

Description John Beimler 2003-08-01 16:09:13 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5a) Gecko/20030730
Mozilla Firebird/0.6.1

Description of problem:
Hardware: Dell Latitude C400

I have noticed that battstat-applet-2 consumes 10-15% of the
processor. It appears that it is the polling of the /proc interface that
causes it.

I have tested this:

$ watch "cat /proc/acpi/ac_adapter/AC/state ; cat /proc/acpi/battery/BAT0/state"

I then watched the cpu usage every second, and it would fluctuate from around
1%-2% when /proc/acpi entries were not being accessed to 10%-15% when they were.
I used top and gnome-system-monitor, if there is a better way to watch this, or
other information is needed, let me know.



Version-Release number of selected component (if applicable):
kernel-2.4.21-20.1.2024.2.1.nptl

How reproducible:
Always

Steps to Reproduce:
1. Monitor ACPI on the laptop, using  battstat-applet-2

    

Actual Results:  CPU usage goes way up while the ACPI state is polled. The
machine can stall if it is under heavy load when ACPI is polled. xmms may skip,
xscreensaver may become jerky and compiles may pause a moment.

Expected Results:  Less CPU usage.

Additional info:

Comment 1 Luming Yu 2003-08-26 09:46:36 UTC
please attach dmesg and output of acpidmp.

thanks.

Comment 2 John Beimler 2003-08-26 14:40:35 UTC
Created attachment 93937 [details]
dmesg from the system

Comment 3 John Beimler 2003-08-26 14:41:19 UTC
Created attachment 93939 [details]
acpidmp from the system

Comment 4 shaohua li 2003-09-03 03:46:56 UTC
can you try this, the change is in routine 'acpi_pci_link_add':
diff -ur a/drivers/acpi/pci_link.c b/drivers/acpi/pci_
link.c
--- a/drivers/acpi/pci_link.c        2003-08-29 08:53:24.000000000 +0
800
+++ b/drivers/acpi/pci_link.c    2003-09-03 11:37:27.000000000 +0
800
@@ -576,7 +576,11 @@
        if (!link->irq.active)
                printk(", disabled");
        else if (!found)
-               printk(", enabled at IRQ %d", link->irq.active);
+       {
+               link->irq.active = 0;
+                acpi_ut_evaluate_object (link->handle, "_DIS", 0, NULL);
+               printk(", disabled");
+       }
        printk(")\n");

        /* TBD: Acquire/release lock */


Comment 5 Len Brown 2004-03-25 00:39:01 UTC
This test runs for me in under 1% CPU use on FC2-test1
closing -- please re-open if you still see this issue.

thanks,
-Len