Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

AOS Lab 8: Interrupts and Device Drivers

1,032 views

Published on

Published in: Technology
  • Be the first to comment

  • Be the first to like this

AOS Lab 8: Interrupts and Device Drivers

  1. 1. Lab 8: Interrupts and Device Drivers Advanced Operating Systems Zubair Nabi zubair.nabi@itu.edu.pk March 28, 2013
  2. 2. Recap of Lab 5: Extraordinary events Events that break normal processor flow, to return control to the kernel: 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
  3. 3. Recap of Lab 5: Extraordinary events Events that break normal processor flow, to return control to the kernel: 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
  4. 4. Recap of Lab 5: Extraordinary events Events that break normal processor flow, to return control to the kernel: 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
  5. 5. Recap of Lab 5: Extraordinary events Events that break normal processor flow, to return control to the kernel: 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
  6. 6. 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 corresponding interrupt handler 5 All the while, maintain isolation between user processes and the kernel
  7. 7. 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 corresponding interrupt handler 5 All the while, maintain isolation between user processes and the kernel
  8. 8. 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 corresponding interrupt handler 5 All the while, maintain isolation between user processes and the kernel
  9. 9. 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 corresponding interrupt handler 5 All the while, maintain isolation between user processes and the kernel
  10. 10. 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 corresponding interrupt handler 5 All the while, maintain isolation between user processes and the kernel
  11. 11. 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 corresponding interrupt handler 5 All the while, maintain isolation between user processes and the kernel
  12. 12. Recap of Lab 5: Handling extraordinary events (2) • Need hardware support • On the x86, system calls generate an interrupt via the int instruction • The same mechanism for handling interrupts is used for handling system calls and exceptions • Traps are caused by the current running process • Interrupts are caused by devices • Can happen concurrently
  13. 13. Recap of Lab 5: Handling extraordinary events (2) • Need hardware support • On the x86, system calls generate an interrupt via the int instruction • The same mechanism for handling interrupts is used for handling system calls and exceptions • Traps are caused by the current running process • Interrupts are caused by devices • Can happen concurrently
  14. 14. Recap of Lab 5: Handling extraordinary events (2) • Need hardware support • On the x86, system calls generate an interrupt via the int instruction • The same mechanism for handling interrupts is used for handling system calls and exceptions • Traps are caused by the current running process • Interrupts are caused by devices • Can happen concurrently
  15. 15. Recap of Lab 5: Handling extraordinary events (2) • Need hardware support • On the x86, system calls generate an interrupt via the int instruction • The same mechanism for handling interrupts is used for handling system calls and exceptions • Traps are caused by the current running process • Interrupts are caused by devices • Can happen concurrently
  16. 16. Recap of Lab 5: Handling extraordinary events (2) • Need hardware support • On the x86, system calls generate an interrupt via the int instruction • The same mechanism for handling interrupts is used for handling system calls and exceptions • Traps are caused by the current running process • Interrupts are caused by devices • Can happen concurrently
  17. 17. Recap of Lab 5: Handling extraordinary events (2) • Need hardware support • On the x86, system calls generate an interrupt via the int instruction • The same mechanism for handling interrupts is used for handling system calls and exceptions • Traps are caused by the current running process • Interrupts are caused by devices • Can happen concurrently
  18. 18. 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 syscall 2 3 Hardware interrupt, it calls the hardware interrupt controller Exception, it prints the details and kills the user process
  19. 19. 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 syscall 2 3 Hardware interrupt, it calls the hardware interrupt controller Exception, it prints the details and kills the user process
  20. 20. 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 syscall 2 3 Hardware interrupt, it calls the hardware interrupt controller Exception, it prints the details and kills the user process
  21. 21. 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 syscall 2 3 Hardware interrupt, it calls the hardware interrupt controller Exception, it prints the details and kills the user process
  22. 22. 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 syscall 2 3 Hardware interrupt, it calls the hardware interrupt controller Exception, it prints the details and kills the user process
  23. 23. Interrupts • Examples of interrupts: Pressing a key on the keyboard, storing data on disk etc. • Hardware on the motherboard signals the CPU whenever a device needs attention • Devices need to be programmed to generate interrupts • Interrupts must be assigned to a CPU for handling
  24. 24. Interrupts • Examples of interrupts: Pressing a key on the keyboard, storing data on disk etc. • Hardware on the motherboard signals the CPU whenever a device needs attention • Devices need to be programmed to generate interrupts • Interrupts must be assigned to a CPU for handling
  25. 25. Interrupts • Examples of interrupts: Pressing a key on the keyboard, storing data on disk etc. • Hardware on the motherboard signals the CPU whenever a device needs attention • Devices need to be programmed to generate interrupts • Interrupts must be assigned to a CPU for handling
  26. 26. Interrupts • Examples of interrupts: Pressing a key on the keyboard, storing data on disk etc. • Hardware on the motherboard signals the CPU whenever a device needs attention • Devices need to be programmed to generate interrupts • Interrupts must be assigned to a CPU for handling
  27. 27. Handing interrupts on multi-processors Two parts of handling interrupts on multi-processors 1 A method to route interrupts to processors (I/O APIC – Advanced Programmable 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
  28. 28. Handing interrupts on multi-processors Two parts of handling interrupts on multi-processors 1 A method to route interrupts to processors (I/O APIC – Advanced Programmable 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
  29. 29. Handing interrupts on multi-processors Two parts of handling interrupts on multi-processors 1 A method to route interrupts to processors (I/O APIC – Advanced Programmable 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
  30. 30. IOAPIC • Interrupts are generated by the APIC labelled from IRQ0 to IRQ16 or IRQ24 • A device enables particular interrupts within the IOAPIC table and specifies which processor they should be routed to • For instance, the keyboard interrupt is routed to CPU0 while disk interrupts are routed to CPU(n − 1), where n is the number of CPUs • Every CPU decides whether it wants to receive interrupts. For instance, scheduler() disables all interrupts
  31. 31. IOAPIC • Interrupts are generated by the APIC labelled from IRQ0 to IRQ16 or IRQ24 • A device enables particular interrupts within the IOAPIC table and specifies which processor they should be routed to • For instance, the keyboard interrupt is routed to CPU0 while disk interrupts are routed to CPU(n − 1), where n is the number of CPUs • Every CPU decides whether it wants to receive interrupts. For instance, scheduler() disables all interrupts
  32. 32. IOAPIC • Interrupts are generated by the APIC labelled from IRQ0 to IRQ16 or IRQ24 • A device enables particular interrupts within the IOAPIC table and specifies which processor they should be routed to • For instance, the keyboard interrupt is routed to CPU0 while disk interrupts are routed to CPU(n − 1), where n is the number of CPUs • Every CPU decides whether it wants to receive interrupts. For instance, scheduler() disables all interrupts
  33. 33. IOAPIC • Interrupts are generated by the APIC labelled from IRQ0 to IRQ16 or IRQ24 • A device enables particular interrupts within the IOAPIC table and specifies which processor they should be routed to • For instance, the keyboard interrupt is routed to CPU0 while disk interrupts are routed to CPU(n − 1), where n is the number of CPUs • Every CPU decides whether it wants to receive interrupts. For instance, scheduler() disables all interrupts
  34. 34. LAPIC • Each CPU has its own LAPIC • xv6 programs the LAPIC using lapicinit()
  35. 35. LAPIC • Each CPU has its own LAPIC • xv6 programs the LAPIC using lapicinit()
  36. 36. Example: Timer interrupt • The kernel uses timer interrupts to get a notion of time and to make scheduling decisions • A value of 100 timer ticks is used by default which is high enough to allow interactivity and low enough not to lead to a live lock • This value is set in lapicinit() and IRQ_TIMER is mapped to IRQ0 • IRQ_TIMER corresponds to interrupt number 32 • In trap(), for interrupt number 32, the timer tick is incremented and processes sleeping on it are woken up
  37. 37. Example: Timer interrupt • The kernel uses timer interrupts to get a notion of time and to make scheduling decisions • A value of 100 timer ticks is used by default which is high enough to allow interactivity and low enough not to lead to a live lock • This value is set in lapicinit() and IRQ_TIMER is mapped to IRQ0 • IRQ_TIMER corresponds to interrupt number 32 • In trap(), for interrupt number 32, the timer tick is incremented and processes sleeping on it are woken up
  38. 38. Example: Timer interrupt • The kernel uses timer interrupts to get a notion of time and to make scheduling decisions • A value of 100 timer ticks is used by default which is high enough to allow interactivity and low enough not to lead to a live lock • This value is set in lapicinit() and IRQ_TIMER is mapped to IRQ0 • IRQ_TIMER corresponds to interrupt number 32 • In trap(), for interrupt number 32, the timer tick is incremented and processes sleeping on it are woken up
  39. 39. Example: Timer interrupt • The kernel uses timer interrupts to get a notion of time and to make scheduling decisions • A value of 100 timer ticks is used by default which is high enough to allow interactivity and low enough not to lead to a live lock • This value is set in lapicinit() and IRQ_TIMER is mapped to IRQ0 • IRQ_TIMER corresponds to interrupt number 32 • In trap(), for interrupt number 32, the timer tick is incremented and processes sleeping on it are woken up
  40. 40. Example: Timer interrupt • The kernel uses timer interrupts to get a notion of time and to make scheduling decisions • A value of 100 timer ticks is used by default which is high enough to allow interactivity and low enough not to lead to a live lock • This value is set in lapicinit() and IRQ_TIMER is mapped to IRQ0 • IRQ_TIMER corresponds to interrupt number 32 • In trap(), for interrupt number 32, the timer tick is incremented and processes sleeping on it are woken up
  41. 41. 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 the device that it manages • Driver also needs to understand the hardware interface of the device
  42. 42. 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 the device that it manages • Driver also needs to understand the hardware interface of the device
  43. 43. 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 the device that it manages • Driver also needs to understand the hardware interface of the device
  44. 44. 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 the device that it manages • Driver also needs to understand the hardware interface of the device
  45. 45. 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 the device that it manages • Driver also needs to understand the hardware interface of the device
  46. 46. 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 the device that it manages • Driver also needs to understand the hardware interface of the device
  47. 47. 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) that maps to one sector • The data within the OS sector structure is often out of sync with the disk • xv6 implements an IDE driver
  48. 48. 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) that maps to one sector • The data within the OS sector structure is often out of sync with the disk • xv6 implements an IDE driver
  49. 49. 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) that maps to one sector • The data within the OS sector structure is often out of sync with the disk • xv6 implements an IDE driver
  50. 50. 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) that maps to one sector • The data within the OS sector structure is often out of sync with the disk • xv6 implements an IDE driver
  51. 51. 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) that maps to one sector • The data within the OS sector structure is often out of sync with the disk • xv6 implements an IDE driver
  52. 52. 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) that maps to one sector • The data within the OS sector structure is often out of sync with the disk • xv6 implements an IDE driver
  53. 53. 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
  54. 54. Example: Disk driver initialization • ideinit() is invoked by main(), which initializes the disk driver 1 ideinit() sets up CPU(n − 1) to handle disk interrupts 2 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 loader and the kernel were obviously loaded from it 3 idewait() polls the status bits of the disk hardware, until IDE_BSY is clear and IDE_DRDY is set 4 It then checks whether another disk is present
  55. 55. Example: Disk driver initialization • ideinit() is invoked by main(), which initializes the disk driver 1 ideinit() sets up CPU(n − 1) to handle disk interrupts 2 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 loader and the kernel were obviously loaded from it 3 idewait() polls the status bits of the disk hardware, until IDE_BSY is clear and IDE_DRDY is set 4 It then checks whether another disk is present
  56. 56. Example: Disk driver initialization • ideinit() is invoked by main(), which initializes the disk driver 1 ideinit() sets up CPU(n − 1) to handle disk interrupts 2 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 loader and the kernel were obviously loaded from it 3 idewait() polls the status bits of the disk hardware, until IDE_BSY is clear and IDE_DRDY is set 4 It then checks whether another disk is present
  57. 57. Example: Disk driver initialization • ideinit() is invoked by main(), which initializes the disk driver 1 ideinit() sets up CPU(n − 1) to handle disk interrupts 2 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 loader and the kernel were obviously loaded from it 3 idewait() polls the status bits of the disk hardware, until IDE_BSY is clear and IDE_DRDY is set 4 It then checks whether another disk is present
  58. 58. Example: Disk driver initialization • ideinit() is invoked by main(), which initializes the disk driver 1 ideinit() sets up CPU(n − 1) to handle disk interrupts 2 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 loader and the kernel were obviously loaded from it 3 idewait() polls the status bits of the disk hardware, until IDE_BSY is clear and IDE_DRDY is set 4 It then checks whether another disk is present
  59. 59. Example: Disk driver initialization • ideinit() is invoked by main(), which initializes the disk driver 1 ideinit() sets up CPU(n − 1) to handle disk interrupts 2 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 loader and the kernel were obviously loaded from it 3 idewait() polls the status bits of the disk hardware, until IDE_BSY is clear and IDE_DRDY is set 4 It then checks whether another disk is present
  60. 60. 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
  61. 61. 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
  62. 62. 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
  63. 63. 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
  64. 64. 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
  65. 65. iderw • Disk accesses take milliseconds of time therefore polling is not an option • iderw keeps the list of pending disk requests in a queue (idequeue) and uses interrupts to signal whenever a request has 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 a read or a write • The current process is then put to sleep waiting for the operation on b to be completed • Once the hardware has completed the operation, it will generate an interrupt (IRQ_IDE) which will be handled by trap by invoking ideintr()
  66. 66. iderw • Disk accesses take milliseconds of time therefore polling is not an option • iderw keeps the list of pending disk requests in a queue (idequeue) and uses interrupts to signal whenever a request has 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 a read or a write • The current process is then put to sleep waiting for the operation on b to be completed • Once the hardware has completed the operation, it will generate an interrupt (IRQ_IDE) which will be handled by trap by invoking ideintr()
  67. 67. iderw • Disk accesses take milliseconds of time therefore polling is not an option • iderw keeps the list of pending disk requests in a queue (idequeue) and uses interrupts to signal whenever a request has 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 a read or a write • The current process is then put to sleep waiting for the operation on b to be completed • Once the hardware has completed the operation, it will generate an interrupt (IRQ_IDE) which will be handled by trap by invoking ideintr()
  68. 68. iderw • Disk accesses take milliseconds of time therefore polling is not an option • iderw keeps the list of pending disk requests in a queue (idequeue) and uses interrupts to signal whenever a request has 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 a read or a write • The current process is then put to sleep waiting for the operation on b to be completed • Once the hardware has completed the operation, it will generate an interrupt (IRQ_IDE) which will be handled by trap by invoking ideintr()
  69. 69. iderw • Disk accesses take milliseconds of time therefore polling is not an option • iderw keeps the list of pending disk requests in a queue (idequeue) and uses interrupts to signal whenever a request has 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 a read or a write • The current process is then put to sleep waiting for the operation on b to be completed • Once the hardware has completed the operation, it will generate an interrupt (IRQ_IDE) which will be handled by trap by invoking ideintr()
  70. 70. iderw • Disk accesses take milliseconds of time therefore polling is not an option • iderw keeps the list of pending disk requests in a queue (idequeue) and uses interrupts to signal whenever a request has 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 a read or a write • The current process is then put to sleep waiting for the operation on b to be completed • Once the hardware has completed the operation, it will generate an interrupt (IRQ_IDE) which will be handled by trap by invoking ideintr()
  71. 71. 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); }
  72. 72. ideintr 1 Checks the first buffer in idequeue to find the type of the operation (read or write) 2 If the operation was a read, it reads the data into the buffer via insl() 3 It then sets B_VALID and clears B_DIRTY and wakes up any processes sleeping on b 4 Finally, it dispatches the next buffer from idequeue
  73. 73. ideintr 1 Checks the first buffer in idequeue to find the type of the operation (read or write) 2 If the operation was a read, it reads the data into the buffer via insl() 3 It then sets B_VALID and clears B_DIRTY and wakes up any processes sleeping on b 4 Finally, it dispatches the next buffer from idequeue
  74. 74. ideintr 1 Checks the first buffer in idequeue to find the type of the operation (read or write) 2 If the operation was a read, it reads the data into the buffer via insl() 3 It then sets B_VALID and clears B_DIRTY and wakes up any processes sleeping on b 4 Finally, it dispatches the next buffer from idequeue
  75. 75. ideintr 1 Checks the first buffer in idequeue to find the type of the operation (read or write) 2 If the operation was a read, it reads the data into the buffer via insl() 3 It then sets B_VALID and clears B_DIRTY and wakes up any processes sleeping on b 4 Finally, it dispatches the next buffer from idequeue
  76. 76. Modern disk controllers in a real OS • Most disk controllers typically accept multiple outstanding disk requests 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
  77. 77. Modern disk controllers in a real OS • Most disk controllers typically accept multiple outstanding disk requests 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
  78. 78. Modern disk controllers in a real OS • Most disk controllers typically accept multiple outstanding disk requests 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
  79. 79. Modern disk controllers in a real OS • Most disk controllers typically accept multiple outstanding disk requests 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
  80. 80. Modern disk controllers in a real OS • Most disk controllers typically accept multiple outstanding disk requests 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
  81. 81. Modern disk controllers in a real OS • Most disk controllers typically accept multiple outstanding disk requests 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
  82. 82. 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 data field 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 the entire process more efficient
  83. 83. 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 data field 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 the entire process more efficient
  84. 84. 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 data field 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 the entire process more efficient
  85. 85. 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 data field 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 the entire process more efficient
  86. 86. 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 data field 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 the entire process more efficient
  87. 87. 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
  88. 88. 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
  89. 89. 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
  90. 90. Reading(s) • Chapter 3, “Traps, interrupts, and drivers”, section “Code: Interrupts" onwards from “xv6: a simple, Unix-like teaching operating system”

×