i o filesystems 1
play

I/O / Filesystems 1 1 last time when LRU fails special-case for - PowerPoint PPT Presentation

I/O / Filesystems 1 1 last time when LRU fails special-case for single-access fjle data readahead handle scans by predicting reads device driver halfs top: from system call, use bufger, request data, wait for data bottom: from interrupt,


  1. I/O / Filesystems 1 1

  2. last time when LRU fails special-case for single-access fjle data readahead — handle scans by predicting reads device driver halfs top: from system call, use bufger, request data, wait for data bottom: from interrupt, fjll bufger, wake up devices as magic memory 2

  3. exercise system is running two applications A: reading from network B: doing tons of computation timeline: A calls read() to 8KB of data from network 16KB of data comes in 10ms later A calls read() again to get 4KB more exercise 1: how many kernel/user mode switches? exercise 2: how many context switches? 3

  4. how many mode switches? 5? user mode (running B) kernel mode depends — does scheduler run A right away? 1 2 3 4? 6? read() syscall 1 2 3 4? 5? 6? 7? 8? user mode (running A) return from A calls read() to 8KB of data from network (driver ‘bottom half’) 16KB of data comes in 10ms later A calls read() again to get 4KB more read() 8KB start wait for device (driver ‘top half’) run B while A waits copy from device mark A ready (driver ‘top half’) run scheduler switch to A (kernel) copy fjrst 8KB (resume driver ‘top half’) return from read() syscall read() syscall copy 4KB from bufger 4

  5. how many mode switches? 5? user mode (running B) kernel mode depends — does scheduler run A right away? 1 2 3 4? 6? read() syscall 1 2 3 4? 5? 6? 7? 8? user mode (running A) return from A calls read() to 8KB of data from network (driver ‘bottom half’) 16KB of data comes in 10ms later A calls read() again to get 4KB more read() 8KB start wait for device (driver ‘top half’) run B while A waits copy from device mark A ready (driver ‘top half’) run scheduler switch to A (kernel) copy fjrst 8KB (resume driver ‘top half’) return from read() syscall read() syscall copy 4KB from bufger 4

  6. how many mode switches? 5? user mode (running B) kernel mode depends — does scheduler run A right away? 1 2 3 4? 6? read() syscall 1 2 3 4? 5? 6? 7? 8? user mode (running A) return from A calls read() to 8KB of data from network (driver ‘bottom half’) 16KB of data comes in 10ms later A calls read() again to get 4KB more read() 8KB start wait for device (driver ‘top half’) run B while A waits copy from device mark A ready (driver ‘top half’) run scheduler switch to A (kernel) copy fjrst 8KB (resume driver ‘top half’) return from read() syscall read() syscall copy 4KB from bufger 4

  7. how many context switches? return from 2 1 depends — does scheduler run A right away? kernel mode user mode (running B) user mode (running A) read() syscall return from (driver ‘top half’) copy 4KB from bufger read() syscall read() syscall (resume driver ‘top half’) A calls read() to 8KB of data from network copy fjrst 8KB switch to A (kernel) run scheduler mark A ready (driver ‘bottom half’) copy from device run B while A waits (driver ‘top half’) wait for device read() 8KB start A calls read() again to get remaining 4KB 16KB of data comes in 10ms later 5

  8. how many context switches? return from 2 1 depends — does scheduler run A right away? kernel mode user mode (running B) user mode (running A) read() syscall return from (driver ‘top half’) copy 4KB from bufger read() syscall read() syscall (resume driver ‘top half’) A calls read() to 8KB of data from network copy fjrst 8KB switch to A (kernel) run scheduler mark A ready (driver ‘bottom half’) copy from device run B while A waits (driver ‘top half’) wait for device read() 8KB start A calls read() again to get remaining 4KB 16KB of data comes in 10ms later 5

  9. direct memory access (DMA) processor interrupt controller memory bus other processors… actual memory other devices device controller external hardware? observation: devices can read/write memory 6 can have device copy data to/from memory

  10. direct memory access (DMA) external hardware? (avoids copy!) passed to read()/etc. location user program best case: OS chooses from device bufger rather than copying OS reads from 0x9000 (instead of internal bufger) write to 0x9000 (this example: 0x9000 (physical)) memory address OS chooses bufgers/queues processor control registers … bufger addr write? read? status device controller other devices actual memory memory bus controller interrupt 7

  11. direct memory access (DMA) external hardware? (avoids copy!) passed to read()/etc. location user program best case: OS chooses from device bufger rather than copying OS reads from 0x9000 (instead of internal bufger) write to 0x9000 (this example: 0x9000 (physical)) memory address OS chooses bufgers/queues processor control registers … bufger addr = 0x9000 write? read? status device controller other devices actual memory memory bus controller interrupt 7

  12. direct memory access (DMA) external hardware? (avoids copy!) passed to read()/etc. location user program best case: OS chooses from device bufger rather than copying OS reads from 0x9000 (instead of internal bufger) write to 0x9000 (this example: 0x9000 (physical)) memory address OS chooses bufgers/queues processor control registers … bufger addr = 0x9000 write? read? status device controller other devices actual memory memory bus controller interrupt 7

  13. direct memory access (DMA) external hardware? (avoids copy!) passed to read()/etc. location user program best case: OS chooses from device bufger rather than copying OS reads from 0x9000 (instead of internal bufger) write to 0x9000 (this example: 0x9000 (physical)) memory address OS chooses bufgers/queues processor control registers … bufger addr = 0x9000 write? read? status device controller other devices actual memory memory bus controller interrupt 7

  14. direct memory access (DMA) external hardware? (avoids copy!) passed to read()/etc. location user program best case: OS chooses from device bufger rather than copying OS reads from 0x9000 (instead of internal bufger) write to 0x9000 (this example: 0x9000 (physical)) memory address OS chooses bufgers/queues processor control registers … bufger addr = 0x9000 write? read? status device controller other devices actual memory memory bus controller interrupt 7

  15. direct memory access (DMA) much faster, e.g., for disk or network I/O avoids having processor run a loop to copy data OS can run normal program during data transfer interrupt tells OS when copy fjnished device uses memory as very large bufger space device puts data where OS wants it directly (maybe) OS specifjes physical address to use… instead of reading from device controller 8

  16. direct memory access (DMA) much faster, e.g., for disk or network I/O avoids having processor run a loop to copy data OS can run normal program during data transfer interrupt tells OS when copy fjnished device uses memory as very large bufger space device puts data where OS wants it directly (maybe) OS specifjes physical address to use… instead of reading from device controller 8

  17. OS puts data where it wants so far: where it wants is the device driver’s bufger seems like OS could also put it directly where application wants it? i.e. pointer passed to read() system call called “zero-copy I/O” should be faster, but, in practice, very rarely done: if part of regular fjle, can’t easily share with page cache device might expect contiguous physical addresses device might expect physical address is at start of physical page device might write data in difgernt format than application expects device might read too much data need to deal with application exiting/being killed before device fjnishes … 9

  18. OS puts data where it wants so far: where it wants is the device driver’s bufger seems like OS could also put it directly where application wants it? i.e. pointer passed to read() system call called “zero-copy I/O” should be faster, but, in practice, very rarely done: if part of regular fjle, can’t easily share with page cache device might expect contiguous physical addresses device might expect physical address is at start of physical page device might write data in difgernt format than application expects device might read too much data need to deal with application exiting/being killed before device fjnishes … 9

  19. OS puts data where it wants so far: where it wants is the device driver’s bufger seems like OS could also put it directly where application wants it? i.e. pointer passed to read() system call called “zero-copy I/O” should be faster, but, in practice, very rarely done: if part of regular fjle, can’t easily share with page cache device might expect contiguous physical addresses device might expect physical address is at start of physical page device might write data in difgernt format than application expects device might read too much data need to deal with application exiting/being killed before device fjnishes … 9

  20. devices summary device controllers connected via memory bus usually assigned physical memory addresses sometimes separate “I/O addresses” (special load/store instructions) controller looks like “magic memory” to OS load/store from device controller registers like memory setting/reading control registers can trigger device operations two options for data transfer programmed I/O: OS reads from/writes to bufger within device controller direct memory access (DMA): device controller reads/writes normal memory 10

Recommend


More recommend