Editing Interrupt (section)

=={{Anchor|AFFINITY|RPS|RFS}}Performance==
Interrupts provide low overhead and good [[Interrupt latency|latency]] at low load, but degrade significantly at high interrupt rate unless care is taken to prevent several pathologies. The phenomenon where the overall system performance is severely hindered by excessive amounts of processing time spent handling interrupts is called an [[interrupt storm]].

There are various forms of [[livelock]]s, when the system spends all of its time processing interrupts to the exclusion of other required tasks.
Under extreme conditions, a large number of interrupts (like very high network traffic) may completely stall the system. To avoid such problems, an [[operating system]] must schedule network interrupt handling as carefully as it schedules process execution.<ref>{{cite journal|url=http://portal.acm.org/citation.cfm?id=263335 |title=Eliminating receive livelock in an interrupt-driven kernel |year=1997 |doi=10.1145/263326.263335 |access-date=2010-11-11|last1=Mogul |first1=Jeffrey C. |last2=Ramakrishnan |first2=K. K. |journal=ACM Transactions on Computer Systems |volume=15 |issue=3 |pages=217–252 |s2cid=215749380 |url-access=subscription }}</ref>

With multi-core processors, additional performance improvements in interrupt handling can be achieved through [[receive-side scaling]] (RSS) when [[multiqueue NIC]]s are used.  Such NICs provide multiple receive [[Queue (abstract data type)|queues]] associated to separate interrupts; by routing each of those interrupts to different cores, processing of the interrupt requests triggered by the network traffic received by a single NIC can be distributed among multiple cores.  Distribution of the interrupts among cores can be performed automatically by the operating system, or the routing of interrupts (usually referred to as ''IRQ affinity'') can be manually configured.<ref name="linux-net-scaling">{{cite web
 | url = https://www.kernel.org/doc/Documentation/networking/scaling.txt
 | title = Documentation/networking/scaling.txt
 | work = Linux kernel documentation
 | date = May 9, 2014 | access-date = November 16, 2014
 | author1 = Tom Herbert | author2 = Willem de Bruijn
 | publisher = [[kernel.org]]
}}</ref><ref>{{cite web
 | url = http://www.intel.com/content/dam/doc/datasheet/82574l-gbe-controller-datasheet.pdf
 | title = Intel 82574 Gigabit Ethernet Controller Family Datasheet
 | date = June 2014 | access-date = November 16, 2014
 | publisher = [[Intel]] | page = 1
}}</ref>

A purely software-based implementation of the receiving traffic distribution, known as ''receive packet steering'' (RPS), distributes received traffic among cores later in the data path, as part of the [[interrupt handler]] functionality.  Advantages of RPS over RSS include no requirements for specific hardware, more advanced traffic distribution filters, and reduced rate of interrupts produced by a NIC.  As a downside, RPS increases the rate of [[inter-processor interrupt]]s (IPIs).  ''Receive flow steering'' (RFS) takes the software-based approach further by accounting for [[application locality]]; further performance improvements are achieved by processing interrupt requests by the same cores on which particular network packets will be consumed by the targeted application.<ref name="linux-net-scaling" /><ref>{{cite web
 | url = https://lwn.net/Articles/362339/
 | title = Receive packet steering
 | date = November 17, 2009 | access-date = November 16, 2014
 | author = Jonathan Corbet | publisher = [[LWN.net]]
}}</ref><ref>{{cite web
 | url = https://lwn.net/Articles/382428/
 | title = Receive flow steering
 | date = April 7, 2010 | access-date = November 16, 2014
 | author = Jake Edge | publisher = [[LWN.net]]
}}</ref>