> > > 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/*'? > > > > what do you see with > > grep . /sys/devices/system/cpu/cpu*/cpuidle/*/* > > > > 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@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
