aos lab 8: interrupts and device drivers
DESCRIPTION
TRANSCRIPT
Lab 8: Interrupts and Device DriversAdvanced Operating Systems
Zubair Nabi
March 28, 2013
Recap of Lab 5: Extraordinary events
Events that break normal processor flow, to return control to thekernel:
1 A device signals that it needs attention (e.g. Timer): Interrupt
2 A user program does something illegal (e.g. divide by zero):Exception
3 A user program asks the kernel for a service: System call
Recap of Lab 5: Extraordinary events
Events that break normal processor flow, to return control to thekernel:
1 A device signals that it needs attention (e.g. Timer): Interrupt
2 A user program does something illegal (e.g. divide by zero):Exception
3 A user program asks the kernel for a service: System call
Recap of Lab 5: Extraordinary events
Events that break normal processor flow, to return control to thekernel:
1 A device signals that it needs attention (e.g. Timer): Interrupt
2 A user program does something illegal (e.g. divide by zero):Exception
3 A user program asks the kernel for a service: System call
Recap of Lab 5: Extraordinary events
Events that break normal processor flow, to return control to thekernel:
1 A device signals that it needs attention (e.g. Timer): Interrupt
2 A user program does something illegal (e.g. divide by zero):Exception
3 A user program asks the kernel for a service: System call
Recap of Lab 5: Handling extraordinary events
The operating system must:
1 Save the processor’s registers for future resumption
2 Set up system for execution in the kernel
3 Choose a place for the kernel to start execution
4 Retrieve information about the event and call correspondinginterrupt handler
5 All the while, maintain isolation between user processes and thekernel
Recap of Lab 5: Handling extraordinary events
The operating system must:
1 Save the processor’s registers for future resumption
2 Set up system for execution in the kernel
3 Choose a place for the kernel to start execution
4 Retrieve information about the event and call correspondinginterrupt handler
5 All the while, maintain isolation between user processes and thekernel
Recap of Lab 5: Handling extraordinary events
The operating system must:
1 Save the processor’s registers for future resumption
2 Set up system for execution in the kernel
3 Choose a place for the kernel to start execution
4 Retrieve information about the event and call correspondinginterrupt handler
5 All the while, maintain isolation between user processes and thekernel
Recap of Lab 5: Handling extraordinary events
The operating system must:
1 Save the processor’s registers for future resumption
2 Set up system for execution in the kernel
3 Choose a place for the kernel to start execution
4 Retrieve information about the event and call correspondinginterrupt handler
5 All the while, maintain isolation between user processes and thekernel
Recap of Lab 5: Handling extraordinary events
The operating system must:
1 Save the processor’s registers for future resumption
2 Set up system for execution in the kernel
3 Choose a place for the kernel to start execution
4 Retrieve information about the event and call correspondinginterrupt handler
5 All the while, maintain isolation between user processes and thekernel
Recap of Lab 5: Handling extraordinary events
The operating system must:
1 Save the processor’s registers for future resumption
2 Set up system for execution in the kernel
3 Choose a place for the kernel to start execution
4 Retrieve information about the event and call correspondinginterrupt handler
5 All the while, maintain isolation between user processes and thekernel
Recap of Lab 5: Handling extraordinary events (2)
• Need hardware support
• On the x86, system calls generate an interrupt via the intinstruction
• The same mechanism for handling interrupts is used for handlingsystem calls and exceptions
• Traps are caused by the current running process• Interrupts are caused by devices
• Can happen concurrently
Recap of Lab 5: Handling extraordinary events (2)
• Need hardware support
• On the x86, system calls generate an interrupt via the intinstruction
• The same mechanism for handling interrupts is used for handlingsystem calls and exceptions
• Traps are caused by the current running process• Interrupts are caused by devices
• Can happen concurrently
Recap of Lab 5: Handling extraordinary events (2)
• Need hardware support
• On the x86, system calls generate an interrupt via the intinstruction
• The same mechanism for handling interrupts is used for handlingsystem calls and exceptions
• Traps are caused by the current running process• Interrupts are caused by devices
• Can happen concurrently
Recap of Lab 5: Handling extraordinary events (2)
• Need hardware support
• On the x86, system calls generate an interrupt via the intinstruction
• The same mechanism for handling interrupts is used for handlingsystem calls and exceptions
• Traps are caused by the current running process• Interrupts are caused by devices
• Can happen concurrently
Recap of Lab 5: Handling extraordinary events (2)
• Need hardware support
• On the x86, system calls generate an interrupt via the intinstruction
• The same mechanism for handling interrupts is used for handlingsystem calls and exceptions
• Traps are caused by the current running process• Interrupts are caused by devices
• Can happen concurrently
Recap of Lab 5: Handling extraordinary events (2)
• Need hardware support
• On the x86, system calls generate an interrupt via the intinstruction
• The same mechanism for handling interrupts is used for handlingsystem calls and exceptions
• Traps are caused by the current running process• Interrupts are caused by devices
• Can happen concurrently
Recap of Lab 5: trap
• Gets passed struct trapframe *tf
• Checks tf->trapno to decide if it was called for a system call(T_SYSCALL) or a hardware interrupt or an exception
• In case of:1 System call, it invokes syscall2 Hardware interrupt, it calls the hardware interrupt controller3 Exception, it prints the details and kills the user process
Recap of Lab 5: trap
• Gets passed struct trapframe *tf
• Checks tf->trapno to decide if it was called for a system call(T_SYSCALL) or a hardware interrupt or an exception
• In case of:1 System call, it invokes syscall2 Hardware interrupt, it calls the hardware interrupt controller3 Exception, it prints the details and kills the user process
Recap of Lab 5: trap
• Gets passed struct trapframe *tf
• Checks tf->trapno to decide if it was called for a system call(T_SYSCALL) or a hardware interrupt or an exception
• In case of:1 System call, it invokes syscall2 Hardware interrupt, it calls the hardware interrupt controller3 Exception, it prints the details and kills the user process
Recap of Lab 5: trap
• Gets passed struct trapframe *tf
• Checks tf->trapno to decide if it was called for a system call(T_SYSCALL) or a hardware interrupt or an exception
• In case of:1 System call, it invokes syscall2 Hardware interrupt, it calls the hardware interrupt controller3 Exception, it prints the details and kills the user process
Recap of Lab 5: trap
• Gets passed struct trapframe *tf
• Checks tf->trapno to decide if it was called for a system call(T_SYSCALL) or a hardware interrupt or an exception
• In case of:1 System call, it invokes syscall2 Hardware interrupt, it calls the hardware interrupt controller3 Exception, it prints the details and kills the user process
Interrupts
• Examples of interrupts: Pressing a key on the keyboard, storingdata on disk etc.
• Hardware on the motherboard signals the CPU whenever adevice needs attention
• Devices need to be programmed to generate interrupts
• Interrupts must be assigned to a CPU for handling
Interrupts
• Examples of interrupts: Pressing a key on the keyboard, storingdata on disk etc.
• Hardware on the motherboard signals the CPU whenever adevice needs attention
• Devices need to be programmed to generate interrupts
• Interrupts must be assigned to a CPU for handling
Interrupts
• Examples of interrupts: Pressing a key on the keyboard, storingdata on disk etc.
• Hardware on the motherboard signals the CPU whenever adevice needs attention
• Devices need to be programmed to generate interrupts
• Interrupts must be assigned to a CPU for handling
Interrupts
• Examples of interrupts: Pressing a key on the keyboard, storingdata on disk etc.
• Hardware on the motherboard signals the CPU whenever adevice needs attention
• Devices need to be programmed to generate interrupts
• Interrupts must be assigned to a CPU for handling
Handing interrupts on multi-processors
Two parts of handling interrupts on multi-processors
1 A method to route interrupts to processors (I/O APIC – AdvancedProgrammable Interrupt Controller, ioapic.c)
2 A per CPU interrupt controller to handle interrupts (Local APIC,lapic.c)
The OS needs to program both the IOAPIC and the LAPIC
Handing interrupts on multi-processors
Two parts of handling interrupts on multi-processors
1 A method to route interrupts to processors (I/O APIC – AdvancedProgrammable Interrupt Controller, ioapic.c)
2 A per CPU interrupt controller to handle interrupts (Local APIC,lapic.c)
The OS needs to program both the IOAPIC and the LAPIC
Handing interrupts on multi-processors
Two parts of handling interrupts on multi-processors
1 A method to route interrupts to processors (I/O APIC – AdvancedProgrammable Interrupt Controller, ioapic.c)
2 A per CPU interrupt controller to handle interrupts (Local APIC,lapic.c)
The OS needs to program both the IOAPIC and the LAPIC
IOAPIC
• Interrupts are generated by the APIC labelled from IRQ0 toIRQ16 or IRQ24
• A device enables particular interrupts within the IOAPIC table andspecifies which processor they should be routed to
• For instance, the keyboard interrupt is routed to CPU0 while diskinterrupts are routed to CPU(n−1), where n is the number ofCPUs
• Every CPU decides whether it wants to receive interrupts. Forinstance, scheduler() disables all interrupts
IOAPIC
• Interrupts are generated by the APIC labelled from IRQ0 toIRQ16 or IRQ24
• A device enables particular interrupts within the IOAPIC table andspecifies which processor they should be routed to
• For instance, the keyboard interrupt is routed to CPU0 while diskinterrupts are routed to CPU(n−1), where n is the number ofCPUs
• Every CPU decides whether it wants to receive interrupts. Forinstance, scheduler() disables all interrupts
IOAPIC
• Interrupts are generated by the APIC labelled from IRQ0 toIRQ16 or IRQ24
• A device enables particular interrupts within the IOAPIC table andspecifies which processor they should be routed to
• For instance, the keyboard interrupt is routed to CPU0 while diskinterrupts are routed to CPU(n−1), where n is the number ofCPUs
• Every CPU decides whether it wants to receive interrupts. Forinstance, scheduler() disables all interrupts
IOAPIC
• Interrupts are generated by the APIC labelled from IRQ0 toIRQ16 or IRQ24
• A device enables particular interrupts within the IOAPIC table andspecifies which processor they should be routed to
• For instance, the keyboard interrupt is routed to CPU0 while diskinterrupts are routed to CPU(n−1), where n is the number ofCPUs
• Every CPU decides whether it wants to receive interrupts. Forinstance, scheduler() disables all interrupts
LAPIC
• Each CPU has its own LAPIC
• xv6 programs the LAPIC using lapicinit()
LAPIC
• Each CPU has its own LAPIC
• xv6 programs the LAPIC using lapicinit()
Example: Timer interrupt
• The kernel uses timer interrupts to get a notion of time and tomake scheduling decisions
• A value of 100 timer ticks is used by default which is high enoughto allow interactivity and low enough not to lead to a live lock
• This value is set in lapicinit() and IRQ_TIMER is mappedto IRQ0
• IRQ_TIMER corresponds to interrupt number 32
• In trap(), for interrupt number 32, the timer tick is incrementedand processes sleeping on it are woken up
Example: Timer interrupt
• The kernel uses timer interrupts to get a notion of time and tomake scheduling decisions
• A value of 100 timer ticks is used by default which is high enoughto allow interactivity and low enough not to lead to a live lock
• This value is set in lapicinit() and IRQ_TIMER is mappedto IRQ0
• IRQ_TIMER corresponds to interrupt number 32
• In trap(), for interrupt number 32, the timer tick is incrementedand processes sleeping on it are woken up
Example: Timer interrupt
• The kernel uses timer interrupts to get a notion of time and tomake scheduling decisions
• A value of 100 timer ticks is used by default which is high enoughto allow interactivity and low enough not to lead to a live lock
• This value is set in lapicinit() and IRQ_TIMER is mappedto IRQ0
• IRQ_TIMER corresponds to interrupt number 32
• In trap(), for interrupt number 32, the timer tick is incrementedand processes sleeping on it are woken up
Example: Timer interrupt
• The kernel uses timer interrupts to get a notion of time and tomake scheduling decisions
• A value of 100 timer ticks is used by default which is high enoughto allow interactivity and low enough not to lead to a live lock
• This value is set in lapicinit() and IRQ_TIMER is mappedto IRQ0
• IRQ_TIMER corresponds to interrupt number 32
• In trap(), for interrupt number 32, the timer tick is incrementedand processes sleeping on it are woken up
Example: Timer interrupt
• The kernel uses timer interrupts to get a notion of time and tomake scheduling decisions
• A value of 100 timer ticks is used by default which is high enoughto allow interactivity and low enough not to lead to a live lock
• This value is set in lapicinit() and IRQ_TIMER is mappedto IRQ0
• IRQ_TIMER corresponds to interrupt number 32
• In trap(), for interrupt number 32, the timer tick is incrementedand processes sleeping on it are woken up
Device Driver
• A piece of code in the OS that manages a particular device• Provides interrupt handlers for a device• Causes a device to perform operations• Causes a device to generate interrupts
• Non-trivial to write as a driver executes concurrently with thedevice that it manages
• Driver also needs to understand the hardware interface of thedevice
Device Driver
• A piece of code in the OS that manages a particular device• Provides interrupt handlers for a device• Causes a device to perform operations• Causes a device to generate interrupts
• Non-trivial to write as a driver executes concurrently with thedevice that it manages
• Driver also needs to understand the hardware interface of thedevice
Device Driver
• A piece of code in the OS that manages a particular device• Provides interrupt handlers for a device• Causes a device to perform operations• Causes a device to generate interrupts
• Non-trivial to write as a driver executes concurrently with thedevice that it manages
• Driver also needs to understand the hardware interface of thedevice
Device Driver
• A piece of code in the OS that manages a particular device• Provides interrupt handlers for a device• Causes a device to perform operations• Causes a device to generate interrupts
• Non-trivial to write as a driver executes concurrently with thedevice that it manages
• Driver also needs to understand the hardware interface of thedevice
Device Driver
• A piece of code in the OS that manages a particular device• Provides interrupt handlers for a device• Causes a device to perform operations• Causes a device to generate interrupts
• Non-trivial to write as a driver executes concurrently with thedevice that it manages
• Driver also needs to understand the hardware interface of thedevice
Device Driver
• A piece of code in the OS that manages a particular device• Provides interrupt handlers for a device• Causes a device to perform operations• Causes a device to generate interrupts
• Non-trivial to write as a driver executes concurrently with thedevice that it manages
• Driver also needs to understand the hardware interface of thedevice
Example: Disk driver
• In charge of copying data back and forth from the disk• Data is represented on the disk as a sequence of sectors, each
containing 512-byte blocks• Sector 0 represents the first 512 bytes, sector 1 the next 512, and
so on
• The OS has a corresponding structure (struct buf) thatmaps to one sector
• The data within the OS sector structure is often out of sync withthe disk
• xv6 implements an IDE driver
Example: Disk driver
• In charge of copying data back and forth from the disk• Data is represented on the disk as a sequence of sectors, each
containing 512-byte blocks• Sector 0 represents the first 512 bytes, sector 1 the next 512, and
so on
• The OS has a corresponding structure (struct buf) thatmaps to one sector
• The data within the OS sector structure is often out of sync withthe disk
• xv6 implements an IDE driver
Example: Disk driver
• In charge of copying data back and forth from the disk• Data is represented on the disk as a sequence of sectors, each
containing 512-byte blocks• Sector 0 represents the first 512 bytes, sector 1 the next 512, and
so on
• The OS has a corresponding structure (struct buf) thatmaps to one sector
• The data within the OS sector structure is often out of sync withthe disk
• xv6 implements an IDE driver
Example: Disk driver
• In charge of copying data back and forth from the disk• Data is represented on the disk as a sequence of sectors, each
containing 512-byte blocks• Sector 0 represents the first 512 bytes, sector 1 the next 512, and
so on
• The OS has a corresponding structure (struct buf) thatmaps to one sector
• The data within the OS sector structure is often out of sync withthe disk
• xv6 implements an IDE driver
Example: Disk driver
• In charge of copying data back and forth from the disk• Data is represented on the disk as a sequence of sectors, each
containing 512-byte blocks• Sector 0 represents the first 512 bytes, sector 1 the next 512, and
so on
• The OS has a corresponding structure (struct buf) thatmaps to one sector
• The data within the OS sector structure is often out of sync withthe disk
• xv6 implements an IDE driver
Example: Disk driver
• In charge of copying data back and forth from the disk• Data is represented on the disk as a sequence of sectors, each
containing 512-byte blocks• Sector 0 represents the first 512 bytes, sector 1 the next 512, and
so on
• The OS has a corresponding structure (struct buf) thatmaps to one sector
• The data within the OS sector structure is often out of sync withthe disk
• xv6 implements an IDE driver
Code: struct buf
struct buf {int flags;uint dev;uint sector;struct buf *prev;struct buf *next;struct buf *qnext;uchar data[512];
};#define B_BUSY 0x1#define B_VALID 0x2#define B_DIRTY 0x4
Example: Disk driver initialization
• ideinit() is invoked by main(), which initializes the diskdriver
1 ideinit() sets up CPU(n−1) to handle disk interrupts2 It then makes a call to idewait() to wait for disk 0 to initialize
• It assumes that at least disk 0 is present because the boot loaderand the kernel were obviously loaded from it
3 idewait() polls the status bits of the disk hardware, untilIDE_BSY is clear and IDE_DRDY is set
4 It then checks whether another disk is present
Example: Disk driver initialization
• ideinit() is invoked by main(), which initializes the diskdriver
1 ideinit() sets up CPU(n−1) to handle disk interrupts2 It then makes a call to idewait() to wait for disk 0 to initialize
• It assumes that at least disk 0 is present because the boot loaderand the kernel were obviously loaded from it
3 idewait() polls the status bits of the disk hardware, untilIDE_BSY is clear and IDE_DRDY is set
4 It then checks whether another disk is present
Example: Disk driver initialization
• ideinit() is invoked by main(), which initializes the diskdriver
1 ideinit() sets up CPU(n−1) to handle disk interrupts2 It then makes a call to idewait() to wait for disk 0 to initialize
• It assumes that at least disk 0 is present because the boot loaderand the kernel were obviously loaded from it
3 idewait() polls the status bits of the disk hardware, untilIDE_BSY is clear and IDE_DRDY is set
4 It then checks whether another disk is present
Example: Disk driver initialization
• ideinit() is invoked by main(), which initializes the diskdriver
1 ideinit() sets up CPU(n−1) to handle disk interrupts2 It then makes a call to idewait() to wait for disk 0 to initialize
• It assumes that at least disk 0 is present because the boot loaderand the kernel were obviously loaded from it
3 idewait() polls the status bits of the disk hardware, untilIDE_BSY is clear and IDE_DRDY is set
4 It then checks whether another disk is present
Example: Disk driver initialization
• ideinit() is invoked by main(), which initializes the diskdriver
1 ideinit() sets up CPU(n−1) to handle disk interrupts2 It then makes a call to idewait() to wait for disk 0 to initialize
• It assumes that at least disk 0 is present because the boot loaderand the kernel were obviously loaded from it
3 idewait() polls the status bits of the disk hardware, untilIDE_BSY is clear and IDE_DRDY is set
4 It then checks whether another disk is present
Example: Disk driver initialization
• ideinit() is invoked by main(), which initializes the diskdriver
1 ideinit() sets up CPU(n−1) to handle disk interrupts2 It then makes a call to idewait() to wait for disk 0 to initialize
• It assumes that at least disk 0 is present because the boot loaderand the kernel were obviously loaded from it
3 idewait() polls the status bits of the disk hardware, untilIDE_BSY is clear and IDE_DRDY is set
4 It then checks whether another disk is present
Buffer cache
• The buffer cache is a linked list of struct buf in memory
• It holds cached copies of disk blocks• Uses iderw(struct buf *b) to read/write a buffer from/to
the disk• If B_DIRTY is set, it writes b to disk• If B_VALID is not set, it reads b from disk
Buffer cache
• The buffer cache is a linked list of struct buf in memory
• It holds cached copies of disk blocks• Uses iderw(struct buf *b) to read/write a buffer from/to
the disk• If B_DIRTY is set, it writes b to disk• If B_VALID is not set, it reads b from disk
Buffer cache
• The buffer cache is a linked list of struct buf in memory
• It holds cached copies of disk blocks• Uses iderw(struct buf *b) to read/write a buffer from/to
the disk• If B_DIRTY is set, it writes b to disk• If B_VALID is not set, it reads b from disk
Buffer cache
• The buffer cache is a linked list of struct buf in memory
• It holds cached copies of disk blocks• Uses iderw(struct buf *b) to read/write a buffer from/to
the disk• If B_DIRTY is set, it writes b to disk• If B_VALID is not set, it reads b from disk
Buffer cache
• The buffer cache is a linked list of struct buf in memory
• It holds cached copies of disk blocks• Uses iderw(struct buf *b) to read/write a buffer from/to
the disk• If B_DIRTY is set, it writes b to disk• If B_VALID is not set, it reads b from disk
iderw
• Disk accesses take milliseconds of time therefore polling is not anoption
• iderw keeps the list of pending disk requests in a queue(idequeue) and uses interrupts to signal whenever a requesthas finished
• It adds b to the end of idequeue• If b is the only buffer in idequeue, it instantly dispatches it to the
disk hardware by calling idestart() which either issues aread or a write
• The current process is then put to sleep waiting for the operationon b to be completed
• Once the hardware has completed the operation, it will generatean interrupt (IRQ_IDE) which will be handled by trap byinvoking ideintr()
iderw
• Disk accesses take milliseconds of time therefore polling is not anoption
• iderw keeps the list of pending disk requests in a queue(idequeue) and uses interrupts to signal whenever a requesthas finished
• It adds b to the end of idequeue• If b is the only buffer in idequeue, it instantly dispatches it to the
disk hardware by calling idestart() which either issues aread or a write
• The current process is then put to sleep waiting for the operationon b to be completed
• Once the hardware has completed the operation, it will generatean interrupt (IRQ_IDE) which will be handled by trap byinvoking ideintr()
iderw
• Disk accesses take milliseconds of time therefore polling is not anoption
• iderw keeps the list of pending disk requests in a queue(idequeue) and uses interrupts to signal whenever a requesthas finished
• It adds b to the end of idequeue• If b is the only buffer in idequeue, it instantly dispatches it to the
disk hardware by calling idestart() which either issues aread or a write
• The current process is then put to sleep waiting for the operationon b to be completed
• Once the hardware has completed the operation, it will generatean interrupt (IRQ_IDE) which will be handled by trap byinvoking ideintr()
iderw
• Disk accesses take milliseconds of time therefore polling is not anoption
• iderw keeps the list of pending disk requests in a queue(idequeue) and uses interrupts to signal whenever a requesthas finished
• It adds b to the end of idequeue• If b is the only buffer in idequeue, it instantly dispatches it to the
disk hardware by calling idestart() which either issues aread or a write
• The current process is then put to sleep waiting for the operationon b to be completed
• Once the hardware has completed the operation, it will generatean interrupt (IRQ_IDE) which will be handled by trap byinvoking ideintr()
iderw
• Disk accesses take milliseconds of time therefore polling is not anoption
• iderw keeps the list of pending disk requests in a queue(idequeue) and uses interrupts to signal whenever a requesthas finished
• It adds b to the end of idequeue• If b is the only buffer in idequeue, it instantly dispatches it to the
disk hardware by calling idestart() which either issues aread or a write
• The current process is then put to sleep waiting for the operationon b to be completed
• Once the hardware has completed the operation, it will generatean interrupt (IRQ_IDE) which will be handled by trap byinvoking ideintr()
iderw
• Disk accesses take milliseconds of time therefore polling is not anoption
• iderw keeps the list of pending disk requests in a queue(idequeue) and uses interrupts to signal whenever a requesthas finished
• It adds b to the end of idequeue• If b is the only buffer in idequeue, it instantly dispatches it to the
disk hardware by calling idestart() which either issues aread or a write
• The current process is then put to sleep waiting for the operationon b to be completed
• Once the hardware has completed the operation, it will generatean interrupt (IRQ_IDE) which will be handled by trap byinvoking ideintr()
Code: iderw
void iderw(struct buf *b){
struct buf **pp;acquire(&idelock);b->qnext = 0;for(pp=&idequeue; *pp; pp=&(*pp)->qnext)
;
*pp = b;if(idequeue == b)
idestart(b);while((b->flags & (B_VALID|B_DIRTY)) != B_VALID){
sleep(b, &idelock);}release(&idelock);
}
ideintr
1 Checks the first buffer in idequeue to find the type of theoperation (read or write)
2 If the operation was a read, it reads the data into the buffer viainsl()
3 It then sets B_VALID and clears B_DIRTY and wakes up anyprocesses sleeping on b
4 Finally, it dispatches the next buffer from idequeue
ideintr
1 Checks the first buffer in idequeue to find the type of theoperation (read or write)
2 If the operation was a read, it reads the data into the buffer viainsl()
3 It then sets B_VALID and clears B_DIRTY and wakes up anyprocesses sleeping on b
4 Finally, it dispatches the next buffer from idequeue
ideintr
1 Checks the first buffer in idequeue to find the type of theoperation (read or write)
2 If the operation was a read, it reads the data into the buffer viainsl()
3 It then sets B_VALID and clears B_DIRTY and wakes up anyprocesses sleeping on b
4 Finally, it dispatches the next buffer from idequeue
ideintr
1 Checks the first buffer in idequeue to find the type of theoperation (read or write)
2 If the operation was a read, it reads the data into the buffer viainsl()
3 It then sets B_VALID and clears B_DIRTY and wakes up anyprocesses sleeping on b
4 Finally, it dispatches the next buffer from idequeue
Modern disk controllers in a real OS
• Most disk controllers typically accept multiple outstanding diskrequests at a time
• They even reorder them to make efficient use of the disk arm• Conceptually other hardware is very similar to disks
• Network buffers hold packets• Audio device buffers hold sound samples• Graphics card buffers hold video data
Modern disk controllers in a real OS
• Most disk controllers typically accept multiple outstanding diskrequests at a time
• They even reorder them to make efficient use of the disk arm• Conceptually other hardware is very similar to disks
• Network buffers hold packets• Audio device buffers hold sound samples• Graphics card buffers hold video data
Modern disk controllers in a real OS
• Most disk controllers typically accept multiple outstanding diskrequests at a time
• They even reorder them to make efficient use of the disk arm• Conceptually other hardware is very similar to disks
• Network buffers hold packets• Audio device buffers hold sound samples• Graphics card buffers hold video data
Modern disk controllers in a real OS
• Most disk controllers typically accept multiple outstanding diskrequests at a time
• They even reorder them to make efficient use of the disk arm• Conceptually other hardware is very similar to disks
• Network buffers hold packets• Audio device buffers hold sound samples• Graphics card buffers hold video data
Modern disk controllers in a real OS
• Most disk controllers typically accept multiple outstanding diskrequests at a time
• They even reorder them to make efficient use of the disk arm• Conceptually other hardware is very similar to disks
• Network buffers hold packets• Audio device buffers hold sound samples• Graphics card buffers hold video data
Modern disk controllers in a real OS
• Most disk controllers typically accept multiple outstanding diskrequests at a time
• They even reorder them to make efficient use of the disk arm• Conceptually other hardware is very similar to disks
• Network buffers hold packets• Audio device buffers hold sound samples• Graphics card buffers hold video data
DMA
• High-bandwidth I/O devices, such as disks, graphics cards,network cards, etc. often use direct memory access (DMA)instead of explicit I/O (insl and outsl)
• Via DMA, controllers get direct access to physical memory
• The device driver passes the physical address of the buffer’s datafield to the device, which copies it from/to the main memory
• Once it is done, it generates an interrupt
• As a result of DMA, the CPU is not involved, hence making theentire process more efficient
DMA
• High-bandwidth I/O devices, such as disks, graphics cards,network cards, etc. often use direct memory access (DMA)instead of explicit I/O (insl and outsl)
• Via DMA, controllers get direct access to physical memory
• The device driver passes the physical address of the buffer’s datafield to the device, which copies it from/to the main memory
• Once it is done, it generates an interrupt
• As a result of DMA, the CPU is not involved, hence making theentire process more efficient
DMA
• High-bandwidth I/O devices, such as disks, graphics cards,network cards, etc. often use direct memory access (DMA)instead of explicit I/O (insl and outsl)
• Via DMA, controllers get direct access to physical memory
• The device driver passes the physical address of the buffer’s datafield to the device, which copies it from/to the main memory
• Once it is done, it generates an interrupt
• As a result of DMA, the CPU is not involved, hence making theentire process more efficient
DMA
• High-bandwidth I/O devices, such as disks, graphics cards,network cards, etc. often use direct memory access (DMA)instead of explicit I/O (insl and outsl)
• Via DMA, controllers get direct access to physical memory
• The device driver passes the physical address of the buffer’s datafield to the device, which copies it from/to the main memory
• Once it is done, it generates an interrupt
• As a result of DMA, the CPU is not involved, hence making theentire process more efficient
DMA
• High-bandwidth I/O devices, such as disks, graphics cards,network cards, etc. often use direct memory access (DMA)instead of explicit I/O (insl and outsl)
• Via DMA, controllers get direct access to physical memory
• The device driver passes the physical address of the buffer’s datafield to the device, which copies it from/to the main memory
• Once it is done, it generates an interrupt
• As a result of DMA, the CPU is not involved, hence making theentire process more efficient
Dynamic interrupt routing
• In case of xv6 all disk interrupts are routed to CPU(n−1)• Real OSes use sophisticated algorithms to dynamically route
interrupts to processors• The goal is to achieve optimum load balancing while maintaining
good locality
Dynamic interrupt routing
• In case of xv6 all disk interrupts are routed to CPU(n−1)• Real OSes use sophisticated algorithms to dynamically route
interrupts to processors• The goal is to achieve optimum load balancing while maintaining
good locality
Dynamic interrupt routing
• In case of xv6 all disk interrupts are routed to CPU(n−1)• Real OSes use sophisticated algorithms to dynamically route
interrupts to processors• The goal is to achieve optimum load balancing while maintaining
good locality
Reading(s)
• Chapter 3, “Traps, interrupts, and drivers”, section “Code:Interrupts" onwards from “xv6: a simple, Unix-like teachingoperating system”