Outline for TodayRole of Interrupts in I/OCPU handles InterruptInterrupt ControlBottom Half ProcessingLottery Scheduling Waldspurger and Weihl (OSDI 94)ClaimsBasic IdeaFairnessExample List-based LotteryBells and WhistlesKernel ObjectsPowerPoint PresentationSlide 20Slide 21CompensationTicket TransferControl ScenariosUIRelative Rate AccuracyFairness Over TimeClient-Server Query Processing RatesControlling Video RatesInsulationOther Kinds of ResourcesLock FundingSlide 34Mutex Waiting Times1Outline for Today•Objectives: –Interrupts (continued)–Lottery Scheduling•AnnouncementsRole of Interrupts in I/OSo, the program needs to access an I/O device…•Start an I/O operation (special instructions or memory-mapped I/O)•Device controller performs the operation asynchronously (in parallel with) CPU processing (between controller's buffer & device).•If DMA, data transferred between controller's buffer and memory without CPU involvement.•Interrupt signals I/O completion when device is done.CPU handles Interrupt•For each interrupt number, jumps to address of appropriate interrupt service routine. [do_IRQ()]–Interrupt context–Kernel stack of whatever was interrupted–Can not sleep•Handlers on this line do what needs to be done. [handle_IRQ_event()]–Unless SA_INTERRUPT specified when registered, re-enable interrupts during handler execution–If line is shared, loop through all handlers•Restores saved state at interrupted instruction [ret_from_intr()],returns to user mode.ldaddstmulbeqldsubbnedo_IRQ()handle_IRQ_eventRet_from_intr()User ProgramInterrupt Handling•Device raises interrupt line, CPU detects this, CPU stops current operation, disables interrupts, enters kernel mode, saves current program counter, jumps to predefined location, saves other processor state needed to continue at interrupted instruction.4Interrupt Control•local_irq_disable() and local_irq_enable() -- affecting all interrupts for this processor•local_irq_save(…) and local_irq_restore(…) –save and disable interrupts on this processor and restore previous interrupt state•disable_irq(irq), disable_irq_nosynch(irq), enable_irq(irq) – affecting particular interrupt line •Informational: –irqs_disabled() – local interrupts disabled?–in_interrupt() – in interrupt context or process context?–In_irq() – executing an interrupt handler?Bottom Half Processing•Deferring work that is too heavyweight for interrupt handling•Mechanisms:–Softirqs“soft interrupts”, statically defined (32 max.) action functions that can run concurrently on SMPpending when bit set in 32-bitmask (usually set in associated interrupt handler [raise_softirq()]run with interrupts enabled, proper locking required–Taskletsdynamically created functions that are built upon softirqs,two of the same type can not run concurrentlylists of tasklet_struct hooked to 2 of the softirqs–Workqueueimplemented as kernel-based “worker” threads with process context of their own -- thus allowed to sleep12Lottery SchedulingWaldspurger and Weihl (OSDI 94)13Claims•Goal: responsive control over the relative rates of computation•Claims:–Support for modular resource management–Generalizable to diverse resources–Efficient implementation of proportional-share resource management: consumption rates of resources by active computations are proportional to relative shares allocated14Basic Idea•Resource rights are represented by lottery tickets–abstract, relative (vary dynamically wrt contention), uniform (handle heterogeneity)–responsiveness: adjusting relative # tickets gets immediately reflected in next lottery•At allocation time: hold a lottery;Resource goes to the computation holding the winning ticket.15Fairness•Expected resource allocation is proportional to # tickets held - actual allocation becomes closer over time.•Throughput – Expected number of lotteries won by clientE[w] = n p where p = t/T•Response time -- # lotteriesto wait for first winE[n] = 1/p•No starvationw # winst # ticketsT total # tickets n # lotteries16Example List-based Lottery102512T = 20Random(0, 19) = 15101217Summing:17Bells and Whistles•Ticket transfers - objects that can be explicitly passed in messages–Can be used to solve priority inversions•Ticket inflation–Create more - used among mutually trusting clients to dynamically adjust ticket allocations•Currencies - “local” control, exchange rates•Compensation tickets - to maintain share with I/O–use only f of quantum, ticket inflated by 1/f in next18Kernel Objects1000baseticketamountcurrencyC_name300BackingticketsIssued ticketsActiveamountCurrencyname19basealicebobtask1task2task3thread2thread3 thread4thread130002005001001002000base1000base200alice200 task2300task2100task3100bob100alice100task101 alice =5 base1 task2=.4 alice =2 base1 bob =20 base20basealicebobtask1task2task3thread2thread3 thread4thread130003005001001002000base1000base200alice200 task2300task2100task3100bob100alice100task11001 alice =3.33 base1 task2=.4 alice =1.33 base1 bob =20 base21Example List-based Lottery10 task22bob 5 task31base2bobT = 3000 baseRandom(0, 2999) = 150022Compensation•A holds 400 base, B holds 400 base•A runs full 100msec quantum,B yields at 20msec•B uses 1/5 allotted timeGets 400/(1/5) = 2000 base at each subsequent lottery for the rest of this quantum –a compensation ticket valued at 2000 - 40023Ticket Transfer•Synchronous RPC between client and server•create ticket in client’s currency and send to server to fund it’s currency•on reply, the transfer ticket is destroyed24Control Scenarios•Dynamic ControlConditionally and dynamically grant ticketsAdaptability•Resource abstraction barriers supported by currencies. Insulate tasks.25UI•mktkt, rmtkt, mkcur, rmcur•fund, unfund•lstkt, lscur, fundx (shell)27Relative Rate Accuracy28Fairness Over Time29Client-ServerQuery Processing Rates30Controlling Video Rates31Insulation32Other Kinds of Resources•Claim: can be used for any resource where queuing is used•Control relative waiting times for mutex locks.–Mutex currency funded out of currencies of waiting threads–Holder gets inheritance ticket in addition to its own funding, passed on to next holder (resulting from lottery) on release.•Space sharing - inverse lottery, loser is victim(e.g. in page replacement decision, processor node preemption in MP partitioning)33Lock FundingWaiting thread1lock1Waiting thread1holding