CPSC 213. Introduction to Computer Systems. I/O Devices, Interrupts and DMA. Unit 2a Mar 12 and 14. Winter Session 2017, Term 2

Transcription

1 CPSC 213 Introduction to Computer Systems Winter Session 2017, Term 2 Unit 2a Mar 12 and 14 I/O Devices, Interrupts and DMA

2 Overview Reading in Text 8.1, 8.2.1, Learning Goals Explain what PIO is, why it exists, what processor originates it, and how it is used Explain what DMA is, why it exists, what it does, and what processor originates it Explain what an interrupt is, why it exists, what it does, and what processor originates it Compare PIO and DMA by identifying when each can be used and when each should be used Compare PIO and interrupts by identify when each can be used and when each should be used Explain the relationship between polling, PIO and interrupts Explain the conditions that make polling acceptable or not Explain what happens when an interrupt occurs at the hardware level Explain what is means for an operation such as a disk read to be asynchronous and give examples of code that works when an operation is synchronous but does not work with it is asynchronous Write event-driven programs in C using function pointers Describe why event-driven programs may be harder to write, read, and debug 2

3 Looking Beyond the CPU and Memory CPU The Processors Memory Bus I/O Bus I/O Controllers Memory I/O Devices Memory Bus data/control path connecting CPU, Main Memory, and I/O Bus also called the Front Side Bus I/O Bus data/control path connecting Memory Bus and I/O Controllers e.g., PCI I/O Controller a processor running software (firmware) connects I/O Device to I/O Bus e.g.,scsi, SATA, Ethernet, I/O Device I/O mechanism that generates or consumes data e.g., disk, radio, keyboard, mouse, 3

4 Talking to an I/O Controller read 0x read 0x1000 addresses 0x0-0x7fffffff 0x x800000ff Programmed I/O (PIO) CPU transfers a word at a time between CPU and I/O controller typically use standard load/store instructions, but to I/O-mapped memory I/O-Mapped Memory memory addresses beyond the end of main memory used to name I/O controllers (usually configured at boot time) loads and stores are translated into I/O-bus messages to controller Example to read/write to controller at address 0x x x800004ff Real Memory I/O Memory ld $0x , r0 st r1 (r0) ld (r0), r1 # write the value of r1 to the device # read a word from device into r1 4

5 Limitations of PIO Reading or writing large amounts of data slows CPU requires CPU to transfer one word at a time controller/device is much slower than CPU and so, CPU runs at controller/device speed, mostly waiting for controller IO Controller can not initiate communication sometimes the CPU asks for data but, sometimes controller receives data for the CPU, without CPU asking - e.g., mouse click or network packet reception (everything is like this really as we will see) how does controller notify CPU that it has data the CPU should want? One not-so-good idea what is it? what are drawbacks? when is it okay? 5

6 Polling and I/O Memory CPU I/O Controller ready value v ready value int polldeviceforvalue () { volatile int* ready = 0x ; volatile int* value = 0x ; int v; while (*ready == 0) {; v = *value; 4 *ready = 0; void readyvalueforcpupoll (int v) { volatile int* ready = 0x ; volatile int* value = 0x ; while (*ready!= 0) {; 1 *value = v; 2 *ready = 1; 3 return v; readyvalueforcpupoll (7); Reading (or writing) I/O Memory IS SLOW CPU -> I/O Device: give me value at address X I/O Device -> CPU: here is value Polling is Okay If poll has low overhead or if high-probability of hit. 6

7 Key Observation The Processors CPU and I/O Controller are independent processors they should be permitted to work in parallel either should be able to initiate data transfer to/from memory either should be able to signal the other to get the other s attention 7

8 Autonomous Controller Operation PIO: data transfer CPU <-> Controller initiated by CPU Interrupt: control transfer controller -> CPU DMA: data transfer Controller <-> Memory initiated by Controller Direct Memory Access (DMA) controller can send/read data from/to any main memory address the CPU is oblivious to these transfers DMA addresses and sizes are programmed by CPU using PIO CPU Interrupts controller can signal the CPU CPU checks for interrupts on every cycle (its like a really fast, clock-speed poll) CPU jumps to controller s Interrupt Service Routine if it is interrupting 8

9 Adding Interrupts to Simple CPU New special-purpose CPU registers isdeviceinterrupting set by I/O Controller to signal interrupt interruptcontrollerid set by I/O Controller to identify interrupting device interruptvectorbase interrupt-handler jump table, initialized a boot time Modified fetch-execute cycle while (true) { if (isdeviceinterrupting) { r[5] r[5] - 4; m[r[5]] r[6]; r[6] pc; pc interruptvectorbase [interruptcontrollerid]; fetch (); execute (); 9 RTI: Return from Interrupt Instruction t r[6]; r[6] m[r[5]]; r[5] r[5] + 4; isdeviceinterrupting 0; pc t;

10 Interrupt Control Flow on CPU Current Program 1. CPU is running a program 2. Controller #0 interrupts 3. CPU detects interrupt 4. CPU jumps to its ISR 5. ISR returns to program ISR - Controller #0 rti ISR - Controller #1 rti ISR - Controller #2 rti ISR - Controller #3 rti 10 interruptvectorbase Register

11 Architectural View of Interrupts CPU I/O Controller 3 isdeviceinterrupting 01 myid 3 interruptcontroller ID 03 7 I/O Controller 7 myid 7 while (true) { if (isdeviceinterrupting) { r[5] r[5] - 4; m[r[5]] r[6]; r[6] pc; pc interruptvectorbase [interruptcontrollerid]; isdeviceinterrupting 0; fetch (); execute (); Polling on CPU register instead of I/O Memory: turning bad polling into good polling 11

12 Programming with I/O

13 Disk Read Timeline CPU 1. PIO to request read I/O Controller 2. PIO Received, start read do other things wait for read to complete 3. Read completes 4. Transfer data to memory (DMA) 6. Interrupt Received Call readcomplete 5. Interrupt CPU A disk stores blocks of data. Each block has a number. CPU can read or write. 13

14 Disk Read Timeline 1 PIO to request read 3 DMA data to memory CPU Memory 4 Interrupt CPU I/O Controllers I/O Devices 2 Transfer data from disk into controller memory CPU PIO Idle or do something else Read block Disk Controller Get block from disk, DMA transfer to Memory, Interrupt CPU Time 14

15 The Power of the Sequence Consider a program that reads data from a disk you can sort of think of the read has having three parts: 1. figure out what data you want 2. get the data 3. do something with the data you got these steps must happen in this order we think of these steps as a sequence For Example int sumdiskdata (blocknum, numbytes) { char buf [numbytes]; int sum = 0; diskread (buf, blocknum, numbytes); for (int i=0; i<numbytes; i++) sum += buf [i]; return sum; 15

16 Meets Reality int sumdiskdata (blocknum, numbytes) { char buf [numbytes]; int sum = 0; diskread (buf, blocknum, numbytes); for (int i=0; i<numbytes; i++) sum += buf [i]; return sum; must wait for read to complete diskread returns disk data in buf read buf to compute sum CPU PIO Idle or do something else Read block Disk Controller Get block from disk, DMA transfer to Memory, Interrupt CPU Time 16

17 Making Code Asynchronous This code requests something char buf[numbytes] diskread (buf, blocknum, numbytes); 2 These two pieces of code are not listed sequentially they are not synchronous int sum = 0; for (int i=0; i<numbytes; i++) sum += buf [i]; This code runs when that thing completes CPU 1 PIO Idle or do something else 3 Read block Disk Controller Get block from disk, DMA transfer to Memory, Interrupt CPU Time 17

18 Writing Asynchronous Code in C Events and Event Handlers the things that causes asynchronous code to run are called events - e.g., disk-read completion the code that runs when an event occurs is called an event handler (or callback) - e.g., the code that computes the checksum handlers are registered to a specific event events are fired to trigger the execution of the handler In Code request and registration of event handler are listed together in the code this code continues does not wait for event handler runs asynchronously when event occurs void computesum (char* buf, int blocknum, int numbytes) { int sum = 0; for (int i=0); i<numbytes; i++) sum += buf [i]; int sum (blocknum, numbytes) { char buf [numbytes]; diskread (buf, blocknum, numbytes, computesum); 18

19 Asynchronous Execution char buf[numbytes] diskread (buf, blocknum, numbytes, computesum); 2 Registration of Handler Event Handler void computesum (char* buf, int blocknum, int numbytes) { int sum = 0; for (int i=0); i<numbytes; i++) sum += buf [i]; CPU Disk Controller Time 1 PIO Event Fired 3 Idle or do something else Read block Get block from disk, DMA transfer to Memory, Interrupt CPU 19

20 Implementing Disk Read (Simplified) Interrupt Vector, Device ID, and PIO Address initialized before all this starts by operating system when device connects #define MAX_DEVICES void (*interruptvector [MAX_DEVICES])(); int diskid = 4; int* diskaddress = (int*) 0x ; interruptvector [diskid] = diskisr; Disk Read register event handler request block (PIO) void diskread (char* buf, int blocknum, int numbytes, void (*whencomplete) (char*, int, int)) { enqueue_handler (whencomplete, buf, blocknum, numbytes); // Perform PIO more in a moment Interrupt Handler find event handler and fire event firing means calling the handler procedure void diskisr() { struct handler_dsc { void (*handler) (char*, int, int); char* buf; int blocknum; int numbytes; ; struct handler_dsc hd; dequeue_handler (&hd); hd.handler (hd.buf, hd.blocknum, hd.numbytes); 20

21 Disk Read PIO Expanded Disk Read with PIO the message sent to disk has several fields each field had different device-memory address access it like a struct - but, keep in mind that writes are to device-memory; - they are messages across bus to device controller they are not writes to main memory void* diskaddress = (void*) 0x ; #DEFINE DISK_OP_READ 1 #DEFINE DISK_OP_WRITE 2 struct disk_ctl { int op; char* buf; int blocknum; int numbytes; void diskread (char* buf, int blocknum, int numbytes, ) { struct disk_ctl* dc = diskaddress; enqueue_handler (whencomplete, buf, blocknum, numbytes); dc->op = DISK_OP_READ; dc->buf = buf; dc->blocknum = blocknum; dc->numbytes = numbytes; 21

22 Did We Really Solve The Problem? We wanted to do this int sumdiskdata (blocknum, numbytes) { char buf [numbytes]; int sum = 0; diskread (buf, blocknum, numbytes); for (int i=0; i<numbytes; i++) sum += buf [i]; return sum; But, reality forced us to do this void computesum (char* buf, int blocknum, int numbytes) { int sum = 0; for (int i=0); i<numbytes; i++) sum += buf [i]; void sumdiskdata (blocknum, numbytes) { char buf [numbytes]; diskread (buf, blocknum, numbytes, computesum); What s wrong? 22

23 Connecting Asynchrony to Program How do we use the value computed from the disk block lets say we want to print it void something () { int s = sumdiskdata (buf, blk, n); printf ( %d\n, s); but asynchronously? void computesum (char* buf, int blocknum, int numbytes) { int sum = 0; for (int i=0); i<numbytes; i++) sum += buf [i]; free (buf); void sumdiskdata (blocknum, numbytes) { char* buf = malloc (numbytes); diskread (buf, blocknum, numbytes, computesum); 23

24 Ordering in Asynchronous Programs If something has to happen after event it must be triggered by the event often this means it must be part of (or called by) event s handler To print the checksum void computesumandprint (char* buf, int blocknum, int numbytes) { int sum = 0; for (int i=0); i<numbytes; i++) sum += buf [i]; printf ( %d\n", sum); free (buf); void sum (blocknum, numbytes, whencomplete) { char* buf = malloc (numbytes); diskread (buf, blocknum, numbytes, whencomplete); sum (1234, 4096, computesumandprint); Huge problem often there s a ton of stuff that depend on returned data that is, that must come after a particular event 24

25 Improving the Code But making it worse void computesumandprint (char* buf, int blocknum, int numbytes) { int sum = 0; for (int i=0); i<numbytes; i++) sum += buf [i]; printf ( %d\n, xsum); // <= TOO SPECIFIC, MAKE THIS A PARAMETER free (buf); void printint (int i) { printf ( %d\n", i); void computesumandcallback (, void (*sumcallback) (int)) { int sum = 0; for (int i=0); i<numbytes; i++) sum += buf [i]; sumcallback (sum); free (buf); What if you want to do something after printint? Welcome to callback hell void sum (blocknum, numbytes, whencomplete, sumcallback) { char* buf = malloc (numbytes); diskread (buf, blocknum, numbytes, whencomplete, sumcallback); sum (1234, 4096, computesumandcallback, printint); 25

26 Happy System, Sad Programmer Humans like synchrony we expect each step of a program to complete before the next one starts we use the result of previous steps as input to subsequent steps with disks, for example, - we read from a file in one step and then usually use the data we ve read in the next step Computer systems are asynchronous the disk controller takes milliseconds (10-3 s) to read a block - CPU can execute 60 million instructions while waiting for the disk to complete one read - we must allow the CPU to do other work while waiting for I/O completion many devices send unsolicited data at unpredictable times - e.g., incoming network packets, mouse clicks, keyboard-key presses - we must allow programs to be interrupted many, many times a second to handle these things Asynchrony makes programmers sad it makes programs more difficult to write and much more difficult to debug 26

27 Possible Solutions Accept the inevitable use an event-driven programming model - event triggering and handling are de-coupled a common idiom in many Java programs - GUI programming follows this model CSP is a language boosts this idea to first-class status - no procedures or procedure calls - program code is decomposed into a set of sequential/synchronous processes - processes can fire events, which can cause other processes to run in parallel - each process has a guard predicate that lists events that will cause it to run - Javascript in web browsers and Node.js embrace asynchrony, albeit awkwardly Invent a new abstraction an abstraction that provides programs the illusion of synchrony but, what happens when - a program does something asynchronous, like disk read? - an unanticipated device event occurs? What s the right solution? we still don t know this is one of the most pressing questions we currently face 27

28 Promises This is an aside that you don t need to know A promise is a placeholder for a asynchronously computed value it is resolved when the value is computed to use the value you prove a function that should run when it is resolve You return a promise like a value you attach handler to the promise s resolve event by calling THEN Common in Javascript in browser and server (Node.js) 28

29 Asynchronous Disk Read with Promises Disk read now returns a promise promise_t diskread (char* buf, int blocknum, int numbytes) { struct diskread_args* args = malloc (sizeof (struct diskread_args)); enqueue_promise (promise_new(), buf, blocknum, numbytes); // PIO to disk to request numbytes of blocknum be sent to buf return args->promise; The promise is resolved by the interrupt void diskisr() { struct diskread_args { promise_t promise; char* buf; int blocknum; int numbytes; ; struct diskread_args* args = dequeue_diskread_args(); promise_resolve (args->promise, args); 29 Compare to Slide 20

30 Simplifies Building on Asynchronous Read You call diskread and then use the promise to use the promise you say what should happen when it resolves when diskread promise is resolved THEN computesum void* computesum (void* v) { struct diskread_args* args = v; int* sum = malloc (sizeof(int)); *sum = 0; for (int i=0; i<args->numbytes; i++) *sum += args->buf[i]; promise_free (args->promise); free (args->buf); free (args); return sum; promise_t sum (blocknum, numbytes) { char* buf = malloc (numbytes); return promise_then (diskread (buf, blocknum, numbytes), computesum); Notice that computesum returns a value THEN returns another promise whose value is result of computechecksum 30 Compare to Slide 22

31 Building on Compute Checksum The key advantage of Promises is that they return values instead of requiring a handler (callback) parameter asynchronous calls thus look like synchronous calls you build on one call using the THEN of its result Building on Compute Checksum void* printint (void* v) { int* sum = v; printf ( 0%d\n", *sum); free (sum); return 0; promise_t printsum (blocknum, numbytes) { return promise_then (sum (blocknum, numbytes), printint); 31 Compare to Slide 25

32 Anonymous (Lambda) Function Improvement Notice that in the previous code we had to define a procedure and give it a name in order to use it as a handler; i.e., pass it to then void* printint (void* v) { int* sum = v; printf ( %d\n", *sum); free (sum); return 0; promise_t printsum (blocknum, numbytes) { return promise_then (sum (blocknum, numbytes), printint); Anonymous functions in clang dialect of C (e.g., Mac), but not gnu dialect (e.g., Linux) use ^ instead of * for function pointers and include procedure code inline promise_t printsum (blocknum, numbytes) { return promise_then (checksum (blocknum, numbytes), ^void* (void* v) { char* xsum = v; printf ( %d\n", *sum); free (sum); return 0; ); 32

33 Putting it all together promise_t sum (blocknum, numbytes) { char* buf = malloc (numbytes); return promise_then (diskread (buf, blocknum, numbytes), ^ void* (void* v) { struct diskread_args* args = v; int* sum = malloc (4); *sum = 0; for (int i=0; i<args->numbytes; i++) *sum += args->buf[i]; promise_free (args->promise); free (args->buf); free (args); return sum; ); promise_t printsum (blocknum, numbytes) { return promise_then (checksum (blocknum, numbytes), ^void* (void* v) { int* sum = v; printf ("0x%1x\n", *sum); free (xsum); return 0; ); printsum (1234, 4096); There is subtle memory leak here, if you see it, great, but don t worry about it. The problem is that printchecksum returns a promise that needs to be freed. Freeing it is a bit tricky. 33

34 An Implementation of Promises struct promise; typedef struct promise* promise_t; struct promise { int resolved; void* value; void* (^callback) (void*); promise_t callbackpromise; ; promise_t promise_new() { promise_t p = malloc (sizeof (struct promise)); p->resolved = 0; p->value = 0; p->callback = 0; p->callbackpromise = 0; return p; void promise_free (promise_t p) { free (p); void promise_resolve (promise_t p, void* v) { p->resolved = 1; p->value = v; if (p->callback) promise_resolve (p->callbackpromise, p->callback (v)); promise_t promise_then (promise_t p, void* (^c) (void*)) { promise_t tp = promise_new(); if (p->resolved) promise_resolve (tp, c (p->value)); else { p->callback = c; p->callbackpromise = tp; return tp; 34

35 If you are taking CPSC 310 You are using AJAX to contact your Express/Node.js server the first A in AJAX stands for asynchronous it works exactly the same way as the diskread example You can use $.ajax with a callback $.ajax({ url: '/blah', success: function (data) { // do something with the data ) Or you can turn it into a Promise Promise.resolve ($.ajax ({url: '/blah')).then (function (data) { // do something with data ) To see the complexity of asynchrony, consider this lets say your application needs to make 2 independent calls via AJAX and then you want a callback to run when the are BOTH complete ideally - you want to make both calls first - then wait for both of them to complete but, how would you do that? its easy with promises, difficult with callbacks 35

36 Using Promises in Javascript To wait for multiple things Promise p1 = Promise.resolve ($.ajax ({url: '/blah')); Promise p2 = Promise.resolve ($.ajax ({url: '/blot')); p1.then (function (p1data) { return p2.then (function (p2data) { // do something with p1data and p2data ) ) 36