本文主要是介绍[中断]/proc/interrupts: Rescheduling Interrupts，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
https://help.ubuntu.com/community/ReschedulingInterrupts
目录
Introduction
What are Rescheduling Interrupts?
Troubleshooting ACPI and APIC problems
Troubleshooting misconfigured hardware
Troubleshooting applications
Introduction
If you are using a laptop then powertop is a useful tool to help reduce power consumption. powertop examines system activity such as the reasons for processor wakeups and reports this periodically.
On some laptops users have seen alarming amounts of "Recheduling Interrupts" (Kernel IPI events) on Hardy systems, which can be caused by several reasons, from incorrect BIOS settings to misbehaving applications. This page will describe how to track down and reduce the amount of processor wakeups, and hopefully increase battery life on a laptop.
如果您使用的是笔记本电脑，那么powertop是有助于降低功耗的有用工具。powertop检查系统活动（例如，处理器唤醒的原因）并定期报告此情况。
在某些笔记本电脑上，用户已经在Hardy系统上看到数量惊人的“重新调度中断”（内核IPI事件），这可能是由于以下几种原因导致的，从错误的BIOS设置到行为异常的应用程序。本页将描述如何追踪和减少处理器唤醒次数，并希望增加笔记本电脑的电池寿命。
What are Rescheduling Interrupts?
With multi core machines, such as Intel Centrino Duos, the scheduler tries to spread processor activity across as many cores as possible. The general rule of thumb is that it is preferable to have as many processes running on all the cores in lower power (lower clock frequencies) rather than have one core really busy running at full speed while other cores are sleeping.
When the scheduler decides to offload work from one core to another sleeping core, a kernel IPI "message" is sent to a sleeping core to wake it up from a low power sleep to make it start running a process. These IPI events are reported by powertop as "Rescheduling Interrupts". The information is available by reading /proc/interrupts - the IPI events are reported as an interrupt.
Generally speaking wakeup events are caused by timer wakeups or interrupts from hardware and these causes processes to be woken up and get scheduled to run. The scheduler will generate IPIs when it deems it necessary to put these woken up processed onto a sleeping core, hence a system with lots of wakeups or interrupts may manifest many "Rescheduling Interrupts".
If powertop is reporting many hundreds or possibly thousands of "Rescheduling Interrupts" then there probably is a problem with a BIOS setting (misconfigured interrupt setup) or a misbehaving application (generating lots of wakeup from timer in threads).
对于Intel Centrino Duos等多核计算机，调度程序将尝试在尽可能多的核之间分配处理器活动。一般的经验法则是，最好让所有内核以更低的功率（更低的时钟频率）运行尽可能多的进程，而不是让一个内核真正忙于全速运行而其他内核处于睡眠状态。
当调度程序决定将工作从一个内核转移到另一个睡眠内核时，会将内核IPI“消息”发送到睡眠内核，以将其从低功耗睡眠唤醒，以使其开始运行进程。Powertop将这些IPI事件报告为“重新计划中断”。可通过读取/ proc / interrupts获得该信息-IPI事件报告为中断。
一般而言，唤醒事件是由定时器唤醒或硬件中断引起的，这些事件会唤醒进程并安排其运行。调度程序认为有必要将这些唤醒的处理过的数据放入睡眠内核时，将生成IPI，因此，具有大量唤醒或中断的系统可能会显示许多“重新调度中断”。
如果powertop报告了数百甚至数千个“重新调度中断”，则可能是BIOS设置（配置错误的中断设置）或应用程序行为异常（从线程中的计时器中产生了很多唤醒）的问题。
Troubleshooting ACPI and APIC problems
ACPI表示高级配置和电源管理接口（Advanced Configuration and Power Management Interface）
APIC标识高级中断控制器
The first thing to try is to see if the ACPI is not configured correctly causing the kernel to configure hardware sub-optimally.
1. Try booting with the "acpi=noirq" kernel parameter
- This will disable IRQ configuration derived from ACPI. If there is no difference with noirq enabled or disabled, this may not be an ACPI IRQ configuration issue.
2. Try booting with the "noapic" kernel parameter
- This will disable the IO-APIC configuration. Again, if there is no difference with it enabled or disabled, this is not an APIC problem.
3. Try booting with "nolapic" kernel parameter
- This disables local APIC. Again, of there is no difference with it enabled or disabled, this is not a local APIC problem.
4. Try booting with the "acpi=off" kernel parameter
- This disables ACPI totally. Again, of there is no difference with it enabled or disabled, this is not a local ACPI problem.
If any of the above solves the problem, then it is advisable to:
1. Check if there is a BIOS upgrade for your machine to see if this fixes the problem. 2. Failing this, one may need to fix one's ACPI configuration, see the ACPIBattery wiki page for more help on how to do this.
尝试做的第一件事是查看ACPI是否配置不正确，导致内核无法最佳地配置硬件。
1.尝试使用“ acpi=noirq”内核参数启动
- 这将禁用从ACPI派生的IRQ配置。如果启用或禁用noirq没什么区别，则可能不是ACPI IRQ配置问题。
2.尝试使用“ noapic”内核参数启动
- 这将禁用IO-APIC配置。同样，如果启用或禁用它没有区别，则这不是APIC问题。
3.尝试使用“ nolapic”内核参数启动
- 这将禁用本地APIC。同样，启用或禁用没有什么区别，这不是本地APIC问题。
4.尝试使用“ acpi=off”内核参数启动
- 这将完全禁用ACPI。同样，启用或禁用它没有什么区别，这不是本地ACPI问题。
如果以上解决了问题，则建议：
1.检查计算机是否有BIOS升级，以解决问题。 2.如果失败，则可能需要修复其ACPI配置，请参阅ACPIBattery Wiki页面，以获取有关执行此操作的更多帮助。
Troubleshooting misconfigured hardware
Of course, hardware maybe misconfigured, causing a device to cause many hundreds of interrupts a second which cause (spurious) wakeups.
Interrupts can be views by cat'ing /proc/interrupts and seeing which interrupt(s) are overly busy. It is worth taking two captures of /proc/interrupts with a 10 second interval between captures and then comparing the difference to find out the busy interrupt line.
Some may be very legitimate, for example, busy ethernet, audio and video hardware, so some judgment is called for to figure out if an interrupt is being correctly generated or not.
If some hardware is misbehaving and producing spurious interrupts it is worth seeing if a kernel module driver that handles the specific interrupt can be removed to see if this stops the problem or not. Failing this, it is worth filing a bug report.
当然，硬件可能配置错误，导致设备每秒引起数百个中断，从而导致（虚假的）唤醒。
可以通过设置/ proc / interrupts并查看哪些中断过于繁忙来查看中断。值得两次捕获/ proc / interrupts，两次捕获之间的间隔为10秒，然后比较差异以找出繁忙的中断行。
有些可能是非常合法的，例如繁忙的以太网，音频和视频硬件，因此需要做出一些判断来确定是否正确生成了中断。
如果某些硬件行为不正常并产生虚假中断，则值得一看的是，是否可以删除处理特定中断的内核模块驱动程序，以查看这是否可以解决问题。如果失败，则值得提交错误报告。
Troubleshooting applications
The final thing to check is to see if the problem is caused by an application that is doing (too many) frequent wakeups. Some applications such as media players have threads that feed the audio and video hardware with data frequently at precise periodic times and can cause many hundreds of wakeup events per second, for example, Amarok when playing back mp3s.
Other applications may have many threads doing animation, for example, the Opera web browser may have several pages open simultaneously, and on each page there may be flash based animations which all can contribute to many tens or hundreds of wakeups per second.
最后要检查的问题是查看问题是否是由执行（太多）频繁唤醒的应用程序引起的。某些应用程序（例如媒体播放器）具有线程，这些线程在精确的周期性时间频繁地向音频和视频硬件提供数据，并且每秒可能会导致数百次唤醒事件，例如，播放mp3时会导致Amarok。
其他应用程序可能有许多执行动画的线程，例如，Opera Web浏览器可能同时打开了多个页面，并且在每个页面上可能有基于Flash的动画，这些动画均可以每秒促成数十或数百次唤醒。
There are several tools available to examine application behavior to pin point rogue programs:
1. Use vmstat 1 to see how busy the overall system is.
有几种工具可用于检查应用程序行为以查明流氓程序：
1.使用vmstat 1查看整个系统的繁忙程度。
procs -----------memory---------- ---swap-- -----io---- -system-- ----cpu----r b swpd free buff cache si so bi bo in cs us sy id wa0 0 15868 27716 58212 379880 0 0 38 106 143 529 7 1 90 20 0 15868 27528 58212 379904 0 0 0 0 167 354 1 0 99 00 0 15868 27596 58220 379904 0 0 0 52 398 1126 11 4 86 0
^CLook at the "in" column to see the number of interrupts a second. If this is very high, then go back and check the interrupts on your system as described in the previous steps above.
Look at the "cs" column to see the number of context switches a second - if this is high there may be (many) applications sleeping and waking causing the scheduler to generate IPI events which show up as "Rescheduling Interrupts".
You may see some tight coupling between 2 processes or threads, e.g. a producer/consumer arrangement where a process does some work and wakes up another to process something and then once this is done the consumer sleeps again waking for the producer. If this occurs very frequently you may see a high amount of context switches a high amount of legitimate "Rescheduling Interrupts" - which is a good sign as it means the scheduler is working to get a good spread of load across the processor cores.
查看“in”列以查看每秒中断数。如果该值很高，请返回并按照上述前面的步骤中所述检查系统上的中断。
查看“ cs”列以查看每秒的上下文切换次数-如果此数量很高，则可能有（许多）应用程序处于睡眠和唤醒状态，从而导致调度程序生成IPI事件，该事件显示为“重新调度中断”。
您可能会看到2个进程或线程之间的紧密联系，例如，生产者/消费者的安排，其中一个进程完成一些工作，然后唤醒另一个进程来处理某些事情，然后一旦完成，消费者便再次为生产者醒来。如果这种情况经常发生，您可能会看到大量上下文切换大量合法的“重新调度中断”-这是一个好兆头，因为这意味着调度程序正在努力在处理器内核之间获得良好的负载分配。
2. Use top to see the which are the busiest processes on your system and see if stopping these applications reduces the wakeups. Sometimes the busiest processes are causing the problem with frequent short sleeps and many hundreds of wakeups.
2.使用top来查看系统中最繁忙的进程，并查看停止这些应用程序是否会减少唤醒。有时最繁忙的过程导致频繁的短暂睡眠和数百次唤醒的问题。
top -b -n 1top - 09:53:07 up 2:15, 4 users, load average: 1.01, 0.53, 0.29
Tasks: 153 total, 1 running, 152 sleeping, 0 stopped, 0 zombie
Cpu(s): 7.1%us, 1.3%sy, 0.1%ni, 89.7%id, 1.7%wa, 0.0%hi, 0.1%si, 0.0%st
Mem: 1026056k total, 1010256k used, 15800k free, 49492k buffers
Swap: 3164764k total, 38048k used, 3126716k free, 251244k cachedPID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 5889 root 20 0 447m 122m 12m S 14 12.2 6:20.88 Xorg
22541 joeuser 20 0 98196 77m 7580 S 12 7.7 0:20.34 frozen-bubble 6290 joeuser 20 0 28920 4584 3800 S 8 0.4 0:09.16 pulseaudio
22266 joeuser 20 0 127m 30m 20m S 6 3.0 0:10.75 amarokapp 6384 joeuser 20 0 25832 18m 7420 S 4 1.8 0:38.22 compiz.real
22588 root 20 0 84460 18m 10m S 4 1.8 0:01.46 etherape
22703 joeuser 20 0 94952 30m 19m S 2 3.1 0:02.51 ekiga 1 root 20 0 2844 1664 520 S 0 0.2 0:01.50 init 2 root 15 -5 0 0 0 S 0 0.0 0:00.00 kthreadd 3 root RT -5 0 0 0 S 0 0.0 0:00.06 migration/0 If you find an application generating far too many wakeups per second, it may be worth filing a bug report against it or trying to fix the problem yourself and supply a patch. Alternatively, finding an alternative application that is aggressive in wakeups may be worth pursuing.
如果您发现一个应用程序每秒产生太多的唤醒，则可能值得针对该应用程序提交错误报告，或者尝试自己解决问题并提供补丁。替代地，寻找激进的替代应用可能是值得追求的。
https://help.ubuntu.com/community/ReschedulingInterrupts
这篇关于[中断]/proc/interrupts: Rescheduling Interrupts的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
