Bug 101467 - Polling /proc/acpi/*/state chews up 10-15% of the processor
Summary: Polling /proc/acpi/*/state chews up 10-15% of the processor
Keywords:
Status: CLOSED UPSTREAM
Alias: None
Product: Red Hat Linux Beta
Classification: Retired
Component: kernel
Version: beta1
Hardware: i386
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Arjan van de Ven
QA Contact: Brian Brock
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2003-08-01 16:09 UTC by John Beimler
Modified: 2007-04-18 16:56 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2004-03-25 00:39:01 UTC
Embargoed:


Attachments (Terms of Use)
dmesg from the system (9.44 KB, text/plain)
2003-08-26 14:40 UTC, John Beimler
no flags Details
acpidmp from the system (62.78 KB, text/plain)
2003-08-26 14:41 UTC, John Beimler
no flags Details

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



Note You need to log in before you can comment on or make changes to this bug.