Is Parallel Programming Hard, And, If So, What Can You Do About It?

322 APPENDIX F. ANSWERS TO QUICK QUIZZESan online CPU, so offline CPUs never have RCUcallbacks, either. Thus, there is no need to invokecallbacks on dynticks-idle or offline CPUs.Quick Quiz D.50:Why would lines 14-17 in Figure D.43 need toadjust the tail pointers?Answer:If any of the tail pointers reference the last callbackin the sublist that was ready to invoke, they mustbe changed to instead reference the ->nxtlistpointer. This situation occurs when the sublistsimmediately following the ready-to-invoke sublistare empty.Quick Quiz D.51:But how does the code in Figure D.45 handle nestedNMIs?Answer:It does not have to handle nested NMIs, becauseNMIs do not nest.Quick Quiz D.52:Why isn’t there a memory barrier between lines 8and 9 of Figure D.47? Couldn’t this cause thecode to fetch even-numbered values from boththe ->dynticks and ->dynticks_nmi fields, eventhough these two fields never were zero at the sametime?Answer:First, review the code in Figures D.44, D.45, andD.46, and note that dynticks and dynticks_nmiwill never have odd values simultaneously (seeespecially lines 6 and 17 of Figure D.45, and recallthat interrupts cannot happen from NMIs).Ofcourse, giventheplacementofthememorybarriersin these functions, it might appear to anotherCPU that both counters were odd at the same time,but logically this cannot happen, and would indicatethat the CPU had in fact passed through dynticksidlemode.Now, let’s suppose that at the time line 8 fetches->dynticks, the value of ->dynticks_nmi was atodd number, and that at the time line 9 fetches->dynticks_nmi, the value of ->dynticks was anodd number. Given that both counters cannot beodd simultaneously, there must have been a timebetween these two fetches when both counters wereeven,andthusatimewhentheCPUwasindynticksidlemode, which is a quiescent state, as required.So, why can’t the && on line 13 of Figure D.47be replaced with an ==? Well, it could be, but thiswould likely be more confusing than helpful.Quick Quiz D.53:Why wait the extra couple jiffies on lines 12-13 inFigure D.55?Answer:This added delay gives the offending CPU a betterchance of reporting on itself, thus getting a decentstack trace of the stalled code. Of course, if theoffending CPU is spinning with interrupts disabled,it will never report on itself, so other CPUs do soafter a short delay.Quick Quiz D.54:What prevents the grace period from ending beforethe stall warning is printed in Figure D.56?Answer:The caller checked that this CPU still had notreported a quiescent state, and because preemptionis disabled, there is no way that a quiescent statecould have been reported in the meantime.Quick Quiz D.55:Why does print_other_cpu_stall() in FigureD.57 need to check for the grace period endingwhen print_cpu_stall() did not?Answer:The other CPUs might pass through a quiescentstate at any time, so the grace period might wellhave ended in the meantime.Quick Quiz D.56:Why is it important that blocking primitivescalled from within a preemptible-RCU read-sidecriticalsectionbesubjecttopriorityinheritance?Answer:Because blocked readers stall RCU grace periods,which can result in OOM. For example, if a readerdid a wait_event() within an RCU read-sidecritical section, and that event never occurred,then RCU grace periods would stall indefinitely,guaranteeing that the system would OOM sooner or