Scribd
Upload
55 views

Topics: Interrupts

This document summarizes a lecture about interrupts. It defines an interrupt as an event external to the currently executing process that causes instruction execution to change. Interrupts are typically generated by hardware devices and are asynchronous to the current process. The document contrasts polling, where the CPU periodically checks devices, with interrupts, where devices signal the CPU via interrupt lines. With interrupts, there is no overhead when no requests are pending. The lecture discusses how operating systems like FreeBSD and Linux handle interrupts in hardware and software.

Uploaded by

yokeswaran
Copyright
© © All Rights Reserved
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
55 views

Topics: Interrupts

This document summarizes a lecture about interrupts. It defines an interrupt as an event external to the currently executing process that causes instruction execution to change. Interrupts are typically generated by hardware devices and are asynchronous to the current process. The document contrasts polling, where the CPU periodically checks devices, with interrupts, where devices signal the CPU via interrupt lines. With interrupts, there is no overhead when no requests are pending. The lecture discusses how operating systems like FreeBSD and Linux handle interrupts in hardware and software.

Uploaded by

yokeswaran
Copyright
© © All Rights Reserved
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
You are on page 1/ 11

Lecture 6:

Interrupts
-Shinu Nair
CSC469

Topics

What is an interrupt?

How do operating systems handle


interrupts?

FreeBSD example

Linux in tutorial

CSC469

Interrupts
Defn
:
an event
external
to the currently
executing process that causes a
change in
the normal flow of instruction
execution;
usually generated by hardware
devices
external to the CPU

From

Design and Implementation of the


FreeBSD Operating System

, Glossary


Key point is that interrupts are
asynchronous
w.r.t
. current process

Typically indicate that some device needs


service
CSC469

Possible Solution: Polling

CPU periodically checks each device


to see
if it needs service

takes CPU time even when no requests


pending

overhead may be reduced at expense of


response time


can be efficient if events arrive rapidly

Polling is like picking up your phone every


few
seconds to see if you have a call.
...
CSC469

Alternative: Interrupts

Give each device a wire (interrupt


line) that
it can use to signal the processor

When interrupt signaled, processor


executes a
routine called an
interrupt handler
to deal with
the interrupt

No overhead when no requests pending

CPU
Interrupt
Controller
Device
Device
Device
Device
Maskable
Non
Maskable
(NMI)
CSC469

Intel 430HX Motherboard

Programmable interrupt
controller (PIC) part of
the

Southbridge

chip

Commonly 8259A chip

8 inputs, 1 output

Can be chained together


Newer systems use

Advanced PIC

(APIC)
for SMP support

Principle is the same


(image from The
Ars
Technica
Motherboard Guide, Dec.
2005, Jon Hannibal Stokes)
CSC469

Polling vs. Interrupts

Polling is like picking up your phone


every few
seconds to see if you have a call.
Interrupts
are like waiting for the phone to ring.

Interrupts win if processor has other


work
to do
and
event response time is not critical

Polling can be better if processor has


to
respond to an event ASAP

May be used in device controller that


contains
dedicated secondary processor
CSC469

Hardware Interrupt Handling

Details are architecture dependent!

Interrupt controller signals CPU that


interrupt has
occurred, passes interrupt number

Interrupts are assigned priorities to handle


simultaneous
interrupts

Lower priority interrupts may be disabled during


service

CPU senses (checks)


interrupt request line
after
every instruction; if raised, then:

uses interrupt number to determine which handler


to start

interrupt vector
associates handlers with interrupts

Basic program state saved (as for system


call)

CPU jumps to interrupt handler

When interrupt done, program state


reloaded and

program resumes
CSC469

Software Interrupt Handling

Typically two parts to interrupt


handling

The part that has to be done immediately

So that device can continue working

The part that should be deferred for later

So that we can respond to the device faster

So that we have a more convenient


execution
context

What does
that
mean?
CSC469

Interrupt Context

Execution of first part of interrupt handler

borrows

the context of whatever was interrupted

Interrupted process state is saved in process


structure

Handler uses interrupted thread

s kernel stack

Have to be
very
careful about stack
allocated data

Handler is not allowed to block

Has no process structure of its own to save state or


allow rescheduling


Can

t call functions that might block (like


kmalloc
)

Handler needs to be kept fast and simple

Typically sets up work for second part, flags that


second
part needs to execute, and re
enables interrupt

You might also like