From: "Paweł Staszewski" <pstaszewski@itcare.pl>
To: Len Brown <lenb@kernel.org>
Cc: linux-acpi@vger.kernel.org
Subject: Re: Strange CPU load - acpi_os_read_port
Date: Thu, 19 Aug 2010 11:11:50 +0200 [thread overview]
Message-ID: <4C6CF556.7030301@itcare.pl> (raw)
In-Reply-To: <alpine.LFD.2.00.1008150958320.2313@localhost.localdomain>
W dniu 2010-08-15 16:05, Len Brown pisze:
>>>> 2217.00 13.7% acpi_os_read_port
>>>>
>>>>
>>> curious.
>>> does /proc/interrupts show you are receiving acpi interrupts?
>>> if yes, what do you see with 'grep . /sys/firmware/acpi/interrupts/*'?
>>>
>>>
cat /proc/interrupts | grep acpi
9: 0 0 0 0 0
0 0 0 0 0 0
0 0 0 0 0 IO-APIC-fasteoi acpi
No interrupts
/sys/firmware/acpi/interrupts/error: 0
/sys/firmware/acpi/interrupts/ff_gbl_lock: 0 enabled
/sys/firmware/acpi/interrupts/ff_pmtimer: 0 invalid
/sys/firmware/acpi/interrupts/ff_pwr_btn: 0 enabled
/sys/firmware/acpi/interrupts/ff_rt_clk: 0 disabled
/sys/firmware/acpi/interrupts/ff_slp_btn: 0 invalid
/sys/firmware/acpi/interrupts/gpe00: 0 invalid
/sys/firmware/acpi/interrupts/gpe01: 0 invalid
/sys/firmware/acpi/interrupts/gpe02: 0 disabled
/sys/firmware/acpi/interrupts/gpe03: 0 disabled
/sys/firmware/acpi/interrupts/gpe04: 0 disabled
/sys/firmware/acpi/interrupts/gpe05: 0 disabled
/sys/firmware/acpi/interrupts/gpe06: 0 enabled
/sys/firmware/acpi/interrupts/gpe07: 0 invalid
/sys/firmware/acpi/interrupts/gpe08: 0 enabled
/sys/firmware/acpi/interrupts/gpe09: 0 disabled
/sys/firmware/acpi/interrupts/gpe0A: 0 enabled
/sys/firmware/acpi/interrupts/gpe0B: 0 disabled
/sys/firmware/acpi/interrupts/gpe0C: 0 disabled
/sys/firmware/acpi/interrupts/gpe0D: 0 disabled
/sys/firmware/acpi/interrupts/gpe0E: 0 disabled
/sys/firmware/acpi/interrupts/gpe0F: 0 invalid
/sys/firmware/acpi/interrupts/gpe10: 0 invalid
/sys/firmware/acpi/interrupts/gpe11: 0 invalid
/sys/firmware/acpi/interrupts/gpe12: 0 invalid
/sys/firmware/acpi/interrupts/gpe13: 0 invalid
/sys/firmware/acpi/interrupts/gpe14: 0 invalid
/sys/firmware/acpi/interrupts/gpe15: 0 invalid
/sys/firmware/acpi/interrupts/gpe16: 0 invalid
/sys/firmware/acpi/interrupts/gpe17: 0 invalid
/sys/firmware/acpi/interrupts/gpe18: 0 invalid
/sys/firmware/acpi/interrupts/gpe19: 0 invalid
/sys/firmware/acpi/interrupts/gpe1A: 0 invalid
/sys/firmware/acpi/interrupts/gpe1B: 0 invalid
/sys/firmware/acpi/interrupts/gpe1C: 0 invalid
/sys/firmware/acpi/interrupts/gpe1D: 0 invalid
/sys/firmware/acpi/interrupts/gpe1E: 0 enabled
/sys/firmware/acpi/interrupts/gpe1F: 0 invalid
/sys/firmware/acpi/interrupts/gpe20: 0 disabled
/sys/firmware/acpi/interrupts/gpe21: 0 invalid
/sys/firmware/acpi/interrupts/gpe22: 0 invalid
/sys/firmware/acpi/interrupts/gpe23: 0 invalid
/sys/firmware/acpi/interrupts/gpe24: 0 invalid
/sys/firmware/acpi/interrupts/gpe25: 0 invalid
/sys/firmware/acpi/interrupts/gpe26: 0 invalid
/sys/firmware/acpi/interrupts/gpe27: 0 invalid
/sys/firmware/acpi/interrupts/gpe28: 0 invalid
/sys/firmware/acpi/interrupts/gpe29: 0 invalid
/sys/firmware/acpi/interrupts/gpe2A: 0 invalid
/sys/firmware/acpi/interrupts/gpe2B: 0 invalid
/sys/firmware/acpi/interrupts/gpe2C: 0 invalid
/sys/firmware/acpi/interrupts/gpe2D: 0 invalid
/sys/firmware/acpi/interrupts/gpe2E: 0 invalid
/sys/firmware/acpi/interrupts/gpe2F: 0 invalid
/sys/firmware/acpi/interrupts/gpe30: 0 invalid
/sys/firmware/acpi/interrupts/gpe31: 0 invalid
/sys/firmware/acpi/interrupts/gpe32: 0 invalid
/sys/firmware/acpi/interrupts/gpe33: 0 invalid
/sys/firmware/acpi/interrupts/gpe34: 0 invalid
/sys/firmware/acpi/interrupts/gpe35: 0 invalid
/sys/firmware/acpi/interrupts/gpe36: 0 invalid
/sys/firmware/acpi/interrupts/gpe37: 0 invalid
/sys/firmware/acpi/interrupts/gpe38: 0 invalid
/sys/firmware/acpi/interrupts/gpe39: 0 invalid
/sys/firmware/acpi/interrupts/gpe3A: 0 invalid
/sys/firmware/acpi/interrupts/gpe3B: 0 invalid
/sys/firmware/acpi/interrupts/gpe3C: 0 invalid
/sys/firmware/acpi/interrupts/gpe3D: 0 invalid
/sys/firmware/acpi/interrupts/gpe3E: 0 invalid
/sys/firmware/acpi/interrupts/gpe3F: 0 invalid
/sys/firmware/acpi/interrupts/gpe_all: 0
/sys/firmware/acpi/interrupts/sci: 0
/sys/firmware/acpi/interrupts/sci_not: 0
>>> what do you see with
>>> grep . /sys/devices/system/cpu/cpu*/cpuidle/*/*
>>>
>>>
ls /sys/devices/system/cpu/cpu0/
cache crash_notes node0 thermal_throttle topology
no cpuidle dir.
grep . /sys/devices/system/cpu/cpuidle/*
/sys/devices/system/cpu/cpuidle/current_driver:acpi_idle
/sys/devices/system/cpu/cpuidle/current_governor_ro:ladder
>>> and if there are IO states, any change if you boot with "idle=halt" or
>>> "idle=mwait"?
>>>
>
>> I can try to reproduce this again but it will take some time.
>>
>> For now the solution for me was:
>>
>> Change configuration for this host and boot with processor.max_cstate=0
>>
> likely it will come back when you remove processor.max_cstate=0,
> and it will go away if you use either idle=halt or idle=mwait or
> processor.max_cstate=1, which are effectively the same.
> (and all preferable to processor.max_cstate-0 from a power
> saving point of view)
>
> If this is true, then you should try processor.max_cstate=N
> where N is 2, 3 etc, depending on the states shown in the
> cpuidle grep above.
>
> If you open a bugzilla and attach the output from acpidump,
> that may also be helpful. If this is due to c-states, the question
> is if for some reason we are not using them optimally.
> If we already are doing what the platform allows, the
> route might be to use PM_QOS to disable states that
> are too expensive.
> (Documentation/power/pm_qos_interface.txt)
>
> cheers,
> Len Brown, Intel Open Source Technology Center.
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
>
>
prev parent reply other threads:[~2010-08-19 9:18 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-07-22 19:39 Strange CPU load - acpi_os_read_port Paweł Staszewski
2010-07-22 19:44 ` Paweł Staszewski
2010-08-15 3:33 ` Len Brown
2010-08-15 10:25 ` Paweł Staszewski
2010-08-15 14:05 ` Len Brown
2010-08-19 9:11 ` Paweł Staszewski [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4C6CF556.7030301@itcare.pl \
--to=pstaszewski@itcare.pl \
--cc=lenb@kernel.org \
--cc=linux-acpi@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).