WEBVTT 00:00:00.969 --> 00:00:05.330 In a weak priority system the currently-running task will always run to completion before 00:00:05.330 --> 00:00:07.970 considering what to run next. 00:00:07.970 --> 00:00:12.541 This means the worst-case latency for a device always includes the worst-case service time 00:00:12.541 --> 00:00:17.099 across all the other devices, i.e., the maximum time we have to wait for 00:00:17.099 --> 00:00:20.749 the currently-running task to complete. 00:00:20.749 --> 00:00:25.349 If there's a long-running task that usually means it will be impossible to meet tight 00:00:25.349 --> 00:00:27.320 deadlines for other tasks. 00:00:27.320 --> 00:00:32.299 For example, suppose disk requests have a 800 us deadline in order to guarantee the 00:00:32.299 --> 00:00:34.640 best throughput from the disk subsystem. 00:00:34.640 --> 00:00:40.950 Since the disk handler service time is 500 us, the maximum allowable latency between 00:00:40.950 --> 00:00:47.040 a disk request and starting to execute the disk service routine is 300 us. 00:00:47.040 --> 00:00:48.040 Oops! 00:00:48.040 --> 00:00:53.700 The weak priority scheme can only guarantee a maximum latency of 800 us, not nearly fast 00:00:53.700 --> 00:00:56.240 enough to meet the disk deadline. 00:00:56.240 --> 00:01:00.670 We can't meet the disk deadline using weak priorities. 00:01:00.670 --> 00:01:05.409 We need to introduce a preemptive priority system that allows lower-priority handlers 00:01:05.409 --> 00:01:09.159 to be interrupted by higher-priority requests. 00:01:09.159 --> 00:01:13.310 We'll refer to this as a "strong" priority system. 00:01:13.310 --> 00:01:16.900 Suppose we gave the disk the highest priority, the printer second priority, and keyboard 00:01:16.900 --> 00:01:20.340 the lowest priority, just like we did before. 00:01:20.340 --> 00:01:25.360 Now when a disk request arrives, it will start executing immediately without having to wait 00:01:25.360 --> 00:01:29.720 for the completion of the lower-priority printer or keyboard handlers. 00:01:29.720 --> 00:01:33.549 The worst-case latency for the disk has dropped to 0. 00:01:33.549 --> 00:01:40.590 The printer can only be preempted by the disk, so it's worst-case latency is 500 us. 00:01:40.590 --> 00:01:46.180 Since it has the lowest priority, the worst-case latency for the keyboard is unchanged at 900 00:01:46.180 --> 00:01:50.100 us since it might still have to wait on the disk and printer. 00:01:50.100 --> 00:01:54.680 The good news: with the proper assignment of priorities, the strong priority system 00:01:54.680 --> 00:02:00.900 can guarantee that disk requests will be serviced by the 800 us deadline. 00:02:00.900 --> 00:02:05.869 We'll need to make a small tweak to our Beta hardware to implement a strong priority system. 00:02:05.869 --> 00:02:13.230 We'll replace the single supervisor mode bit in PC[31] with, say, a three-bit field (PRI) 00:02:13.230 --> 00:02:19.310 in PC[31:29] that indicates which of the eight priority levels the processor is currently 00:02:19.310 --> 00:02:20.310 running at. 00:02:20.310 --> 00:02:23.940 Next, we'll modify the interrupt mechanism as follows. 00:02:23.940 --> 00:02:30.160 In addition to requesting an interrupt, the requesting device also specifies the 3-bit 00:02:30.160 --> 00:02:32.560 priority it was assigned by the system architect. 00:02:32.560 --> 00:02:37.210 We'll add a priority encoder circuit to the interrupt hardware to select the highest-priority 00:02:37.210 --> 00:02:45.660 request and compare the priority of that request (PDEV) to the 3-bit PRI value in the PC. 00:02:45.660 --> 00:02:51.950 The system will take the interrupt request only if PDEV > PRI, i.e., if the priority 00:02:51.950 --> 00:02:56.380 of the request is *higher* than the priority the system is running at. 00:02:56.380 --> 00:03:02.950 When the interrupt is taken, the old PC and PRI information is saved in XP, and the new 00:03:02.950 --> 00:03:08.770 PC is determined by the type of interrupt and the new PRI field is set to PDEV. 00:03:08.770 --> 00:03:14.640 So the processor will now be running at the higher priority specified by the device. 00:03:14.640 --> 00:03:20.090 A strong priority system allows low-priority handlers to be interrupted by higher-priority 00:03:20.090 --> 00:03:24.180 requests, so the worst-case latency seen at high priorities 00:03:24.180 --> 00:03:29.540 is unaffected by the service times of lower-priority handlers. 00:03:29.540 --> 00:03:34.000 Using strong priorities allows us to assign a high priority to devices with tight deadlines 00:03:34.000 --> 00:03:37.629 and thus guarantee their deadlines are met. 00:03:37.629 --> 00:03:42.930 Now let's consider the impact of recurring interrupts, i.e., multiple interrupt requests 00:03:42.930 --> 00:03:44.860 from each device. 00:03:44.860 --> 00:03:49.460 We've added a "maximum frequency" column to our table, which gives the maximum rate at 00:03:49.460 --> 00:03:53.470 which requests will be generated by each device. 00:03:53.470 --> 00:03:57.700 The execution diagram for a strong priority system is shown below the table. 00:03:57.700 --> 00:04:03.540 Here we see there are multiple requests from each device, in this case shown at their maximum 00:04:03.540 --> 00:04:06.349 possible rate of request. 00:04:06.349 --> 00:04:11.040 Each tick on the timeline represent 100 us of real time. 00:04:11.040 --> 00:04:19.709 Printer requests occur every 1 ms (10 ticks), disk requests every 2 ms (20 ticks), and keyboard 00:04:19.709 --> 00:04:23.820 requests every 10 ms (100 ticks). 00:04:23.820 --> 00:04:28.540 In the diagram you can see that the high-priority disk requests are serviced as soon as they're 00:04:28.540 --> 00:04:30.290 received. 00:04:30.290 --> 00:04:35.190 And that medium-priority printer requests preempt lower-priority execution of the keyboard 00:04:35.190 --> 00:04:37.060 handler. 00:04:37.060 --> 00:04:41.810 Printer requests would be preempted by disk requests, but given their request patterns, 00:04:41.810 --> 00:04:46.960 there's never a printer request in progress when a disk request arrives, so we don't see 00:04:46.960 --> 00:04:48.680 that happening here. 00:04:48.680 --> 00:04:54.580 The maximum latency before a keyboard requests starts is indeed 900 us. 00:04:54.580 --> 00:04:56.730 But that doesn't tell the whole story! 00:04:56.730 --> 00:05:01.280 As you can see, the poor keyboard handler is continually preempted by higher-priority 00:05:01.280 --> 00:05:07.300 disk and printer requests and so the keyboard handler doesn't complete until 3 ms after 00:05:07.300 --> 00:05:09.160 its request was received! 00:05:09.160 --> 00:05:14.470 This illustrates why real-time constraints are best expressed in terms of deadlines and 00:05:14.470 --> 00:05:16.330 not latencies. 00:05:16.330 --> 00:05:21.440 If the keyboard deadline had been less that 3 ms, even the strong priority system would 00:05:21.440 --> 00:05:24.460 have failed to meet the hard real-time constraints. 00:05:24.460 --> 00:05:29.620 The reason would be that there simply aren't enough CPU cycles to meet the recurring demands 00:05:29.620 --> 00:05:33.419 of the devices in the face of tight deadlines. 00:05:33.419 --> 00:05:38.120 Speaking of having enough CPU cycles, there are several calculations we need to do when 00:05:38.120 --> 00:05:40.830 thinking about recurring interrupts. 00:05:40.830 --> 00:05:45.770 The first is to consider how much load each periodic request places on the system. 00:05:45.770 --> 00:05:52.110 There's one keyboard request every 10 ms and servicing each request takes 800 us, which 00:05:52.110 --> 00:05:58.080 consumes 800us/10ms = 8% of the CPU. 00:05:58.080 --> 00:06:03.550 A similar calculation shows that servicing the disk takes 25% of the CPU and servicing 00:06:03.550 --> 00:06:07.290 the printer takes 40% of the CPU. 00:06:07.290 --> 00:06:14.050 Collectively servicing all the devices takes 73% of the CPU cycles, leaving 27% for running 00:06:14.050 --> 00:06:16.240 user-mode programs. 00:06:16.240 --> 00:06:21.009 Obviously we'd be in trouble if takes more than 100% of the available cycles to service 00:06:21.009 --> 00:06:22.889 the devices. 00:06:22.889 --> 00:06:28.430 Another way to get in trouble is to not have enough CPU cycles to meet each of the deadlines. 00:06:28.430 --> 00:06:35.080 We need 500/800 = 67.5% of the cycles to service the disk in the time between the disk request 00:06:35.080 --> 00:06:37.979 and disk deadline. 00:06:37.979 --> 00:06:42.670 If we assume we want to finish serving one printer request before receiving the next, 00:06:42.670 --> 00:06:46.479 the effective printer deadline is 1000 us. 00:06:46.479 --> 00:06:52.750 In 1000 us we need to be able to service one higher-priority disk request (500 us) and, 00:06:52.750 --> 00:06:56.400 obviously, the printer request (400 us). 00:06:56.400 --> 00:07:02.220 So we'll need to use 900 us of the CPU in that 1000 us interval. 00:07:02.220 --> 00:07:05.000 Whew, just barely made it! 00:07:05.000 --> 00:07:09.389 Suppose we tried setting the keyboard deadline to 2000 us. 00:07:09.389 --> 00:07:14.990 In that time interval we'd also need to service 1 disk request and 2 printer requests. 00:07:14.990 --> 00:07:23.140 So the total service time needed is 500 + 2*400 + 800 = 2100 us. 00:07:23.140 --> 00:07:30.509 Oops, that exceeds the 2000 us window we were given, so we can't meet the 2000 us deadline 00:07:30.509 --> 00:07:33.860 with the available CPU resources. 00:07:33.860 --> 00:07:38.550 But if the keyboard deadline is 3000 us, let's see what happens. 00:07:38.550 --> 00:07:44.600 In a 3000 us interval we need to service 2 disk requests, 3 printer requests, and, of 00:07:44.600 --> 00:07:54.210 course, 1 keyboard request, for a total service time of 2*500 + 3*400 + 800 = 3000 us. 00:07:54.210 --> 00:07:55.210 Whew! 00:07:55.210 --> 00:07:55.469 Just made it!