Preemptible-RCU CPU hotplugging while maintaining real-time response

Abstract

A grace period detection technique for a preemptible read-copy update (RCU) implementation that uses a combining tree for quiescent state tracking. When a leaf level bitmask indicating online/offline CPUs is fully cleared due to all of its assigned CPUs going offline as a result of hotplugging operations, the bitmask state is not immediately propagated to the root level of the combining tree as in prior art RCU implementations. Instead, propagation is deferred until all tasks are removed from an associated leaf level task list tracking tasks that were preempted inside an RCU read-side critical section. Deferring bitmask propagation obviates the need to migrate the task list to the combining tree root level in order to prevent premature grace period termination. The task list can remain at the leaf level. In this way, CPU hotplugging is accommodated while avoiding excessive degradation of real-time latency stemming from the now-eliminated task list migration.

Claims

1. A hierarchical read-copy update (RCU) grace period detection method that accommodates CPU-hotplugging while avoiding degradation of real-time latency due to task list migration, comprising: providing a combining tree of two or more levels to track quiescent states, said levels including a leaf level and a root level; determining whether a condition warrants adjusting hierarchical RCU grace period detection to account for CPUs that have gone offline due to hotplugging operations; said condition being met if (1) a leaf level bitmask of said combining tree is fully cleared to indicate an offline state in which all of its assigned CPUs are offline, and (2) there are no tasks on a task list associated with said fully cleared bitmask; if said condition is met, then propagating said offline state of said leaf level bitmask up said combining tree to a root level bitmask to thereby establish an adjusted grace period detection state in which said fully cleared bitmask's assigned CPUs are ignored for purposes of grace period detection; if said condition is partially met due to said leaf level bitmask being fully cleared to indicate an offline state in which all of its assigned CPUs are offline, but there are tasks remaining on said task list associated with said fully cleared bitmask, then (3) refraining from propagating said offline state up said combining tree to said root level bitmask and (4) maintaining said associated task list at said leaf level without migration to said root level, thereby ensuring that said tasks remaining on said task list will continue to have effect for purposes of grace period detection without having to migrate said task list; and unless said condition is fully met, continuing existing grace period detection without propagating said offline state.

2. The method of claim 1, wherein said determining whether a condition warrants adjusting said hierarchical RCU grace period detection to account for CPUs that have gone offline due to a hotplugging operation is performed whenever said hotplugging operation results in said leaf level bitmask being fully cleared to indicate said offline state.

3. The method of claim 1, wherein said determining whether a condition warrants adjusting said hierarchical RCU grace period detection to account for CPUs that have gone offline due to a hotplugging operation is performed whenever a last remaining task of said task list is removed from said task list.

4. The method of claim 1, wherein locking synchronization is provided between said periodically clearing fields of said leaf level bitmask and said propagating said offline state of said leaf level bitmask up said combining tree to said root level bitmask.

5. The method of claim 1, wherein said levels of said combining tree each comprise one or more data structures, each of which maintains a bitmask, said data structures at said leaf level each further maintain a task list.

6. The method of claim 1, wherein each of said leaf level bitmasks comprises one bit for each CPU assigned said leaf level bitmask, and wherein said root level bitmask comprises one bit for each lower level bitmask assigned to said root level bitmask.

7. The method of claim 1, wherein said tasks lists each comprise a first list portion containing tasks that are blocking a current grace period and second list portion containing tasks that are blocking a next grace period.

Description

BRIEF DESCRIPTION OF THE DRAWINGS

(1) The foregoing and other features and advantages will be apparent from the following more particular description of example embodiments, as illustrated in the accompanying Drawings.

(2) FIGS. 1A-1D are diagrammatic representations of a linked list of data elements undergoing a data element replacement according to a conventional read-copy update mechanism.

(3) FIGS. 2A-2C are diagrammatic representations of a linked list of data elements undergoing a data element deletion according to a conventional read-copy update mechanism.

(4) FIG. 3 is a flow diagram illustrating an example prior art grace period in which four processes pass through a quiescent state.

(5) FIG. 4 is a functional block diagram showing an example prior art hierarchical RCU implementation.

(6) FIG. 5 is a functional block diagram showing a multiprocessor computing system.

(7) FIG. 6 is a functional block diagram showing an example RCU subsystem that may be provided in the computer system of FIG. 5.

(8) FIG. 7A is a functional block diagram showing the prior art hierarchical RCU implementation of FIG. 4 prior to all CPUs of a leaf rcu_node structure going offline, with the ->qsmaskinit bitmasks of the leaf and root rcu_node structures reflecting this fact, and with the leaf rcu_node structure having two preempted tasks on its ->blkd_tasks list, one blocking a current grace period and the other blocking a subsequent grace period.

(9) FIG. 7B is a functional block diagram corresponding to FIG. 7A, but following all CPUs of a leaf rcu_node structure going offline, with the ->qsmaskinit bitmask of the leaf rcu_node structure being updated to reflect this fact, with the ->qsmaskinit state of the leaf having been propagated to a corresponding field of the root rcu_node structure's ->qsmaskinit bitmask, and with the leaf rcu_node structure's ->blkd_tasks list having been migrated to the root rcu_node structure.

(10) FIG. 8A is a functional block diagram showing a hierarchical RCU implementation operating in accordance with the hierarchical RCU grace period detection technique disclosed herein, prior to all CPUs of a leaf rcu_node structure going offline, with the ->qsmaskinit bitmasks of the leaf and root rcu_node structures reflecting this fact, and with the leaf rcu_node structure having preempted tasks on its ->blkd_tasks list, one blocking a current grace period and the other blocking a subsequent grace period.

(11) FIG. 8B is a functional block diagram corresponding to FIG. 8A, but following all CPUs of a leaf node rcu_node structure going offline, with the ->qsmaskinit bitmask of the leaf rcu_node structure being updated to reflect this fact, but with the root rcu_node structure's ->qsmaskinit bitmask not being updated at this time, and with the leaf node rcu_node structure's ->blkd_tasks list not being migrated to the root rcu_node structure.

(12) FIG. 8C is a functional block diagram corresponding to FIG. 8B, but at a point where the leaf rcu_node structure's ->blkd_tasks list has no preempted task blocking a current grace period and one preempted task blocking a subsequent grace period.

(13) FIG. 8D is a functional block diagram corresponding to FIG. 8C, but at a point where the leaf rcu_node structure's ->blkd_tasks list has no preempted tasks blocking any grace periods, and with the root rcu_node structure's qsmaskinit bitmask being updated to reflect the state of the leaf rcu_node structure having no online CPUs and no preempted tasks on its ->blkd_tasks list.

(14) FIG. 9 is a flow diagram illustrating example generalized operations of the hierarchical RCU grace period detection technique disclosed herein.

(15) FIG. 10 is a diagrammatic illustration showing example computer readable data storage media that may be used to provide a computer program product in accordance with the present disclosure.

DETAILED DESCRIPTION OF EXAMPLE EMBODIMENTS

(16) Turning now to the figures, wherein like reference numerals represent like elements in all of the several views, FIG. 5 illustrates an example multiprocessor computer system in which the hierarchical RCU grace period detection technique described herein may be implemented. In FIG. 5, a computer system 2 includes a plurality of processors 4.sub.1, 4.sub.2 . . . 4.sub.n, a system bus 6, and a program memory 8. There are also cache memories 10.sub.1, 10.sub.2 . . . 10.sub.n and cache controllers 12.sub.1, 12.sub.2 . . . 12.sub.n respectively associated with the processors 4.sub.1, 4.sub.2 . . . 4.sub.n. A memory controller 14 is associated with the memory 8. As shown, the memory controller 14 may reside separately from processors 4.sub.2 . . . 4.sub.n (e.g., as part of a chipset). As discussed below, it could also comprise plural memory controller instances residing on the processors 4.sub.1, 4.sub.2 . . . 4.sub.n.

(17) The computer system 2 may represent any of several different types of computing apparatus. Such computing apparatus may include, but are not limited to, general purpose computers, special purpose computers, portable computing devices, communication and/or media player devices, set-top devices, embedded systems, and other types of information handling machines. The term processor as used with reference to the processors 4.sub.1, 4.sub.2 . . . 4.sub.n encompasses any program execution unit capable of executing program instructions, including but not limited to a packaged integrated circuit device (such as a microprocessor), a processing core within a packaged integrated circuit device (such as a microprocessor core), or a hardware thread comprising one or more functional units within a processing core (such as an SMT thread). Each such execution unit may also be referred to as a CPU (central processing unit). The processors 4.sub.1, 4.sub.2 . . . 4.sub.n may be situated within a single computing device or node (e.g., as part of a single-node SMP system) or they may be distributed over plural nodes (e.g., as part of a NUMA system, a cluster, or a cloud). The memory 8 may comprise any type of tangible storage medium capable of storing data in computer readable form for use in program execution, including but not limited to, any of various types of random access memory (RAM), various flavors of programmable read-only memory (PROM) (such as flash memory), and other types of primary storage (i.e., program memory). The cache memories 10.sub.1, 10.sub.2 . . . 10.sub.n may be implemented in several levels (e.g., as level 1, level 2 and level 3 caches) and the cache controllers 12.sub.1, 12.sub.2 . . . 12.sub.n may collectively represent the cache controller logic that supports each cache level. As illustrated, the memory controller 14 may reside separately from processors 4.sub.1, 4.sub.2 . . . 4.sub.n, for example, as part of a discrete chipset. Alternatively, as previously mentioned, the memory controller 14 could be provided by plural memory controller instances that are respectively integrated with the processors 4.sub.1, 4.sub.2 . . . 4.sub.n.

(18) Each CPU embodied by a given processor 4 is operable to execute program instruction logic under the control of a software program stored in the memory 8 (or elsewhere). As part of this program execution logic, update operations (updaters) 18 may execute within a process, thread, or other execution context (hereinafter task) on any of the processors 4. Each updater 18 runs periodically to perform updates on a set of shared data 16 that may be stored in the shared memory 8 (or elsewhere). In FIG. 5, reference numerals 18.sub.1, 18.sub.2 . . . 18.sub.n illustrate individual data updaters that respectively execute on the several processors 4.sub.1, 4.sub.2 . . . 4.sub.n. As described in the Background section above, the updates performed by an RCU updater can include modifying elements of a linked list, inserting new elements into the list, deleting elements from the list, and other types of operations. To facilitate such updates, the processors 4 may be programmed from instructions stored in the memory 8 (or elsewhere) to implement a read-copy update (RCU) subsystem 20 as part of their processor functions. In FIG. 5, reference numbers 20.sub.1, 20.sub.2 . . . 20.sub.n represent individual RCU instances that may respectively periodically execute on the several processors 4.sub.1, 4.sub.2 . . . 4.sub.n. Operational details of the RCU subsystem 20 are described below.

(19) Any given processor 4 may also periodically execute a read operation (reader) 21. Each reader 21 runs from program instructions stored in the memory 8 (or elsewhere) in order to periodically perform read operations on the set of shared data 16 stored in the shared memory 8 (or elsewhere). In FIG. 5, reference numerals 21.sub.1, 21.sub.2 . . . 21.sub.n illustrate individual reader instances that may respectively execute on the several processors 4.sub.1, 4.sub.2 . . . 4.sub.n. Such read operations will typically be performed far more often than updates, this being one of the premises underlying the use of read-copy update. Moreover, it is possible for several of the readers 21 to maintain simultaneous references to one of the shared data elements 16 while an updater 18 updates the same data element.

(20) For purposes of the present disclosure, it is assumed that the readers 21 may be preempted while executing within their RCU read-side critical sections. This would be the case, for example, if the readers 21 embody kernel code paths in a preemptible operating system kernel. To accommodate such reader preemption, the RCU subsystem 20 is embodied as a preemptible RCU implementation.

(21) During operation of the computer system 2, an updater 18 will occasionally perform an update to one of the shared data elements 16. In accordance with the philosophy of RCU, a first-phase update may be performed in a manner that temporarily preserves a pre-update view of the shared data element for the benefit of readers 21 that may be concurrently referencing the shared data element during the update operation. Following the first-phase update, the updater 18 may invoke an RCU primitive such as synchronize_rcu( ) to invoke the RCU subsystem 20 to track a grace period for deferred destruction of the pre-update view of the data (second-phase update). The grace period processing performed by the RCU subsystem 20 entails starting new grace periods and detecting the end of old grace periods so that the RCU subsystem 20 knows when it is safe to free stale data (or take other actions).

(22) Turning now to FIG. 6, example components of the RCU subsystem 20 are shown. Among these components is a set of RCU subsystem support functions 30, namely, an RCU reader API (Application Programming Interface) 32, an RCU updater API 34, and a set of grace period detection functions 36.

(23) The RCU reader API 32 may comprise a reader registration component and a reader unregistration component that are respectively invoked by readers 21 as they enter and leave their RCU read-side critical sections to read shared data 16. This allows the RCU subsystem 20 to track reader operations and determine when readers are engaged in RCU-protected read-side critical section processing. In an example embodiment, the reader registration and unregistration components may be respectively implemented using the rcu_read_lock( ) and rcu_read_unlock( ) primitives found in existing read-copy update implementations.

(24) The RCU updater API 34 may comprise a synchronization primitive such as synchronize_rcu( ) for use by updaters 18 to defer the removal of shared data 16 that may be referenced by the readers 21 until the grace period detection component 36 determines that a grace period has elapsed.

(25) The grace period detection component 36 of the RCU subsystem 20 includes various functions that participate in starting new grace periods and detecting the end of old grace periods. The grace period detection component 36 further includes an improved mechanism to facilitate improved hierarchical RCU grace period detection during CPU hotplugging, while avoiding excessive degradation of real-time latency due to task list migration. The operational details of this improved mechanism are described in more detail below.

(26) With continuing reference now to FIG. 6, the RCU subsystem 20 further includes a set of RCU subsystem data structures 50. These data structures include an rcu_state structure 52 having embedded therein (e.g., as a linear array) a combining tree of rcu_node structures 54. The RCU subsystem 20 thus supports hierarchical grace period detection, and may therefore be characterized as a hierarchical RCU implementation. The tree of rcu_node structures tracks quiescent states, with ->qsmask and ->qsmaskinit bitmasks at each level of the tree (not shown in FIG. 6) respectively indicating which CPU's quiescent states are still required in order to end current and future grace periods. Leaf rcu_node structures 54 also maintain a ->blkd_tasks list (not shown in FIG. 6) to track readers 21 that have been preempted within their RCU read-side critical sections. The use of ->lock fields (not shown in FIG. 6) within the rcu_node structures 54 serializes access to the ->qsmask and ->qsmaskinit bitmasks and the ->blkd_tasks lists. Each leaf rcu_node structure 54 additionally has a set of a per-processor rcu_data structures 56 assigned to it. Each rcu_data structure 56 represents one CPU in the computer system 2.

(27) As discussed in the Background section above, the last CPU of a leaf rcu_node structure 54 can go offline while the leaf rcu_node structure's ->blkd_tasks list is non-empty. In prior art RCU implementations, the offline state of the leaf rcu_node structure's ->qsmaskinit bitmask is promptly propagated up the rcu_node tree hierarchy to the root rcu_node structure. At the same time, grace period stalling is prevented by migrating the ->blkd_tasks list of the leaf rcu_node structure to the root rcu_node structure. As indicated at the conclusion of the Background section above, the inventor named herein has observed that this strategy can result in a real-time performance penalty due to the overhead associated with the list moving operations, such as having to repeatedly release and acquire the ->locks of the leaf and root rcu_node structures as the tasks are migrated one at a time.

(28) The improved hierarchical RCU grace period detection technique disclosed herein overcomes this problem. When a leaf rcu_node structure's ->qsmaskinit bitmask is fully cleared due to all of its assigned CPUs going offline as a result of hotplugging operations, the bitmask state is not immediately propagated to the root rcu_node structure as in prior art RCU implementations. Instead, propagation is deferred until all tasks are removed from the leaf rcu_node structure's ->blkd_tasks list. Deferring bitmask propagation obviates the need to migrate the ->blkd_tasks list to the root rcu_node structure in order to prevent premature grace period termination. The ->blkd_tasks list can remain at the leaf rcu_node structure. In this way, CPU hotplugging is accommodated while avoiding excessive degradation of real-time latency stemming from the now-eliminated task list migration operation.

(29) Before describing the foregoing technique in more detail, it will be helpful to illustrate an example of the prior art grace period detection approach that uses ->blkd_tasks list migration. Turning now to FIGS. 7A and 7B, a simplified view of an rcu_state structure 52 is shown. The rcu_state structure 52 embodies an RCU hierarchy that includes a root rcu_node structure 54A and two leaf rcu_node structures 54B (Node0) and 54C (Node1). Two rcu_data structures 56A and 56B (respectively corresponding to CPU0 and CPU1) report to the leaf rcu_node structure 54B. Two more rcu_data structures 56C and 56D (respectively corresponding to CPU2 and CPU3) report to the other leaf rcu_node structure 54C. Both leaf rcu_node structures 54B and 54C report to the root level rcu_node structure 54A.

(30) In FIG. 7A, CPU0, CPU2 and CPU3 are online and CPU1 is offline. This is reflected in the ->qsmaskinit bitmasks of the leaf rcu_node structures 54B and 54C, each of which is abbreviated qsmi. The rcu_node structure 54C has its ->qsmaskinit bitmask set to 0b11 , indicating that both its CPUs (CPU2 and CPU3) are online. The rcu_node structure 54B has its ->qsmaskinit bitmask set to 0b01, indicating that CPU0 is online but CPU1 is offline. The root rcu_node structure 54A has its ->qsmaskinit mask set to 0b11, indicating that both of its subordinate leaf rcu_node structures 54B and 54B have at least one online CPU. Note that the rcu_node structures 54 will also have a ->lock field and a ->qsmask bitmask, as described above, but these are not shown to facilitate ease of understanding.

(31) The leaf rcu_node structure 54B is shown to be tracking two tasks (designated A and B) that have been preempted while in their current RCU read-side critical sections while running on a CPU assigned to the leaf rcu_node structure 54B (i.e., CPU0 or CPU1). Both tasks are therefore members of the ->blkd_tasks list of leaf rcu_node structure 54B. The tag t in FIGS. 7A and 7B signifies a ->blkd_tasks pointer representing the head of the ->blkd_tasks list. The tag g in FIGS. 7A and 7B signifies a ->gp_tasks pointer representing the beginning of a tail portion of the ->blkd_tasks list that contains tasks blocking the current grace period. Because task B is on this tail portion of the ->blkd_tasks list, task B began its RCU read-side critical section before the beginning of the current RCU grace period. Therefore, the ->gp_tasks pointer g of the leaf rcu_node structure 54B references it, indicating that the current grace period must wait for task B to exit its RCU read-side critical section. Task A, on the the other hand, began its RCU read-side critical section after the beginning of the current RCU grace period, so it appears in the ->blkd_tasks list before the ->gp_tasks pointer, indicating that the current grace period need not wait on it, although the next grace period must do so.

(32) Offlining CPU 0 using the prior-art scheme would result in the state shown in FIG. 7B. Here, the leaf rcu_node structure 54B has both ->qsmaskinit bits cleared, indicating that both of its CPUs (CPU0 and CPU1) are now offline. Moreover, the fully offline CPU state indicated by the ->qsmaskinit bitmask of the leaf rcu_node structure 54B is propagated to the ->qsmaskinit bitmask of the root rcu_node structure 54A. This results in the root rcu_node structure 54A having its low-order ->qsmaskinit bit cleared, indicating that the rcu_node structure 54B (Node0) has no online CPUs and may now be ignored by the grace period detection function 36 of FIG. 6. Relatedly, the ->blkd_tasks list of preempted tasks that was associated with the leaf rcu_node structure 54B leaf has been migrated to the root rcu_node structure 54A. The current grace period will now correctly wait for task B and the next grace period will correctly wait for task A, but with the real-time latency penalty caused by the ->blkd_tasks list migration.

(33) The hierarchical RCU grace period detection technique proposed herein will now be described with reference to the example shown in FIGS. 8A-8D. These figures use the same rcu_state, rcu_node and rcu_data structures shown in FIGS. 7A and 7B. The operations to be described may be implemented as part of the grace period detection function 36 shown in FIG. 6, or they may be implemented in some other portion of the RCU subsystem 20.

(34) FIG. 8A shows the same initial state as in FIG. 7A. CPU0, CPU2 and CPU3 are online and CPU1 is offline. The ->blkd_tasks list of the leaf rcu_node structure 54B has tasks A and B, with task B blocking the current grace period and task A blocking the next grace period.

(35) FIGS. 8B-8D illustrate several stages of operation to handle the scenario where CPU0 assigned to leaf rcu_node structure 54B goes offline, such that there are no long any online CPUs associated with that rcu_node structure. The first stage is shown in FIG. 8B. Here, CPU0 has gone offline, but unlike FIG. 7B, the ->blkd_tasks list of the leaf rcu_node structure 54B remains in place and is not migrated to the root rcu_node structure 54A. Also, the bit associated with the leaf rcu_node structure 54B remains set in the root rcu_node structure's ->qsmaskinit bitmask. Instead of propagating the fully offline CPU state indicated by the ->qsmaskinit bitmask of the leaf rcu_node structure 54B to the ->qsmaskinit bitmask of the root rcu_node structure 54A, as in FIG. 7A, there is no propagation at this point.

(36) Propagation as used herein refers to clearing ->qsmaskinit bits up the hierarchy of rcu_node structures 54 of the rcu_state structure 52, with each lower level rcu_node structure clearing its assigned bit in the higher level rcu_node structure to which it reports. In FIG. 8B, such propagation can be be deferred due to maintaining Tasks A and B on the leaf rcu_node structure's ->blkd_tasks list. As a result of deferring propagation, the grace period detection function 36 of the RCU subsystem 20 continues to assume (from the state of the root rcu_node structure's ->qsmaskinit bitmask) that there is something in the leaf rcu_node structure 54B that must be waited on (tasks A and B in this case), such that the leaf rcu_node structure cannot be ignored for purposes of grace period detection. All that has changed is that the bit associated with CPU0 in the ->qsmaskinit bitmask of the leaf rcu_node structure 54B has been cleared to indicate the newly offlined state of CPU 0.

(37) As shown in FIG. 8C, when task B exits from its RCU read-side critical section, it will remove itself from the ->blkd_tasks list of the leaf rcu_node structure 54B. Assuming that CPU2 and CPU3 associated with the leaf rcu_node structure 54C have also passed through a quiescent state for the current grace period, the removal of task B will allow the current grace period to complete. As an aside, current grace period detection is handled by manipulating the ->qsmask bitmasks of the rcu_node structures 54A, 54B and 54C. As noted in the Background section above, an rcu_node structure's ->qsmask bitmask indicates when CPUs or groups of CPUs have passed through a quiescent state that on which the current grace period depends. For ease of understanding, the ->qsmask bitmasks of the rcu_node structures 54A, 54B and 54C are not shown. Nor are the rcu_node structure ->lock fields.

(38) With continued reference to FIG. 8C, task A remains in its RCU read-side critical section, and therefore will block the next grace period. It is maintained on the ->blkd_tasks list of the leaf rcu_node structure 54B. At this point, there is still no propagation of the fully offline CPU state indicated by the ->qsmaskinit bitmask of the leaf rcu_node structure 54B to the ->qsmaskinit bitmask of the root rcu_node structure 54A. The root rcu_node structure's ->qsmaskinit bitmask bit corresponding to the leaf rcu_node structure 54B remains set, indicating to the grace period detection function 36 that this leaf rcu_node structure must still be accounted for during grace period detection.

(39) Turning now to FIG. 8D, task A has finally exited its RCU read-side critical section and the ->blkd_tasks list of the leaf rcu_node structure 54B is empty. A two part condition now holds in which the ->qsmaskinit bitmask of the leaf rcu_node structure 54 is fully cleared, and its ->blkd_tasks list is empty. Based on this condition, the fully offline CPU state indicated by the ->qsmaskinit bitmask of the leaf rcu_node structure 54B is now propagated to the ->qsmaskinit bitmask of the root rcu_node structure 54A. The result is that the bit in the root's ->qsmaskinit bitmask corresponding to the leaf rcu_node structure 54B is cleared. At this point, the grace period detection function 36 determines that there is no longer a need to wait for anything on the leaf rcu_node structure 54B, and that leaf rcu_node may be ignored for purposes of grace period detection.

(40) Of course, it is possible that either CPU0 or CPU1 might have come online in the meantime. Had this happened, the ->qsmaskinit bitmask of the leaf rcu_node structure 54B would have been non-zero when task A exited its RCU read-side critical section. This this condition would have prevented any propagation of the ->qsmaskinit bitmask state of the leaf rcu_node structure 54B to the root rcu_node structure 54A because bitmask propagation requires that a leaf rcu_node structure's ->qsmaskinit bitmask be fully cleared. The bit in the root rcu_node structure's ->qsmaskinit bitmask that corresponds to the leaf rcu_node structure 54B would remain set, and the grace period detection function 36 would continue to track the leaf rcu_node structure 54B.

(41) Contrasting the operations of FIGS. 8A-8D with the prior art grace period detection technique shown in FIGS. 7A-7B, all tasks on a leaf rcu_node structure's ->blkd_tasks list are allowed to remain on the leaf rcu_node structure instead of migrating them to the root rcu_node structure, even after all CPUs corresponding to the leaf rcu_node structure have gone offline. Compensating for this refusal to migrate tasks is the deferred propagation of ->qsmaskinit bitmask clearing up the rcu_node tree until after the last task on the leaf rcu_node structure's ->blkd_tasks list has exited its outermost RCU read-side critical section. By so doing, the completion of grace periods will be blocked as needed while still maintaining low levels of lock contention (and thus providing for high scalability) and also maintaining good real-time latencies.

(42) Turning now to FIG. 9, generalized hierarchical RCU grace period detection operations for producing the state changes in FIGS. 8A-8D are shown. These operations, which are applicable to any type of preemptible read-copy update (RCU) implementation, illustrate generally how improved hierarchical RCU grace period detection may be achieved during CPU hotplugging while avoiding excessive degradation of real-time latency due to task list migration. As used herein, a hierarchical RCU implementation may represent any form of RCU that uses a combining tree of two or more levels to track quiescent states, the levels including a leaf level and a root level. In the embodiment of FIGS. 8A-8D, the combining tree was implemented as a hierarchy rcu_node structures, as shown in FIG. 5. However, other forms of combining tree could also be used.

(43) The combining tree may have at least one bitmask at each of the levels indicating which CPU's are offline and whose quiescent states are not required to end a grace period, each leaf level bitmask having fields associated with a set of assigned CPUs, and the root level bitmask having fields associated with a set of lower level bitmasks. The combining tree may further have one or more task lists at the leaf level identifying tasks that were preempted while in an RCU read-side critical section and are blocking a grace period. Each leaf level task list is associated with a set of assigned CPUs that is also assigned to one of the leaf level bitmasks, such that each of the leaf level tasks lists is thereby associated with one of the leaf level bitmasks. In the embodiment of FIGS. 8A-8D, the bitmasks were provided by rcu_node structure ->qsmaskinit bitmasks, and the task lists were provided by rcu_node structure ->blkd_tasks lists. However, other types of bitmasks and task lists could be used.

(44) Periodically, the fields of the leaf level bitmasks are cleared as the CPUs assigned to those bitmasks go offline. These operations are exemplified by block 100 in FIG. 9. Block 100 represents a hotplugging operation in which a CPU goes offline and clears itself from is assigned leaf level bitmask. If the RCU subsystem data structures 50 of FIG. 6 are being used, block 100 would entail clearing a bit in the ->qsmaskinit bitmask of a CPU's leaf rcu_node structure 54. In a specific embodiment, block 100 may be implemented by modifying the existing hierarchical RCU function known as rcu_cleanup_dead_cpu( ), which currently performs the prior art ->blkd_tasks list migration operations, the modification being to remove the task migration functionality and add logic that invokes block 104 (see below) when the last CPU to go offline clears the ->qsmaskint bit mask of its leaf rcu_node structure 54.

(45) Periodically, tasks are removed from the task lists as the tasks exit their RCU read-side critical sections. These operations are exemplified by block 102 in FIG. 9. Block 102 represents an RCU blocked reader assistance operation in which a task that was preempted during an RCU read-side critical section exits that critical section and is the last task removed from a leaf level task list associated with the CPU on which the task was running at the time of preemption. If the RCU subsystem data structures 50 of FIG. 6 are being used, block 102 would entail the task removing itself from the ->blkd_task list of the CPU's leaf rcu_node structure. In a specific embodiment, block 102 may be implemented by modifying the existing hierarchical RCU function known as rcu_read_unlock_special( ) the modification being to invoke block 104 (see below) when the last task is removed from the leaf rcu_node structure's ->blkd_task list.

(46) Block 104 of FIG. 9 follows blocks 100 and 102. In block 104, a determination is made whether a condition warrants adjusting hierarchical RCU grace period detection to account for CPUs that have gone offline due to hotplugging operations. The condition is met if (1) one of the leaf level bitmasks is fully cleared to indicate an offline state in which all of its assigned CPUs are offline, and (2) there are no tasks on the task list associated with the fully cleared bitmask. If the RCU subsystem data structures 50 of FIG. 6 are being used, the first part of the condition of block 104 would be determined to be satisfied when the ->qsmaskinit bitmask of a leaf rcu_node structure 54 is completely cleared, indicating that all CPUs for this leaf rcu_node structure are offline. The second part of the condition of block 104 would be determined to be satisfied when the leaf rcu_node structure's ->blkd_tasks list is empty.

(47) Block 106 exemplifies a state where the condition checked for in block 104 is not met. In that case, processing returns to the caller, and existing grace period detection is continued without adjusting the grace period detection state to account for newly offlined CPUs. Note that block 106 may be reached if neither part of the condition checked for in block 104 is satisfied. Moreover, block 106 will be reached if condition checked for in block 104 is only partially met because one of the condition's two parts remain unsatisfied.

(48) Of particular interest is the state where the condition is only partially met due to one of the leaf level bitmasks (e.g., a leaf rcu_node structure's ->qsmaskinit bitmask) being fully cleared to indicate an offline state in which all of its assigned CPUs are offline, but there are tasks remaining on the task list associated with the fully cleared bitmask (e.g., the same leaf rcu_node structure's ->blkd_tasks list). In that case, the return from processing in block 106 means that the offline state of the leaf level bitmask is not propagated up the combining tree to the root level bitmask, and the task lists are maintained at the leaf level without migration to the root level. This ensures that the tasks remaining on the task list will continue to have effect for purposes of grace period detection without having to migrate the tasks list.

(49) Block 108 exemplifies a state where the condition checked for in block 104 is met. In that case, the offline state of the leaf level bitmask (e.g., a leaf rcu_node structure's ->qsmaskinit bitmask) is propagated up the combining tree to the root level bitmask (e.g., the root rcu_node structure's ->qsmaskinit bitmask) to thereby establish an adjusted grace period detection state in which the leaf rcu_node structure and anything else associated with the fully cleared bitmask are now ignored for purposes of grace period detection.

(50) Note that locking synchronization between the CPU hotplug operation in block 100 and the propagation operation of block 108, both of which can manipulate the same leaf level bitmask (e.g., a leaf rcu_node structure's ->qsmaskinit bitmask), may be provided by a leaf level lock. If the RCU subsystem data structures 50 of FIG. 6 are being used, the lock would be provided by a leaf rcu_node structure's ->lock field. This lock would be held in order to clear a bit in a ->qsmaskinit bitmask, and while propagating the state of a fully cleared ->qsmaskinit bitmask up the rcu_node structure hierarchy.

(51) Accordingly, a technique has been disclosed for use in a preemptible read-copy update (RCU) implementation to facilitate improved hierarchical RCU grace period detection during CPU hotplugging while avoiding excessive degradation of real-time latency due to task list migration. It will be appreciated that the foregoing concepts may be variously embodied in any of a data processing system, a machine implemented method, and a computer program product in which programming logic is provided by one or more computer readable data storage media for use in controlling a data processing system to perform the required functions. Example embodiments of a machine-implemented method and data processing system were previously described in connection with FIGS. 5-9.

(52) With respect to a computer program product, digitally encoded program instructions may be stored on one or more computer readable data storage media for use in controlling a computer or other information handling machine or device to perform the required functions. The program instructions may be embodied as machine language code that is ready for loading and execution by the machine apparatus, or the program instructions may comprise a higher level language that can be assembled, compiled or interpreted into machine language. Example languages include, but are not limited to C, C++, assembly, to name but a few. When implemented on a machine comprising a processor, the program instructions combine with the processor to provide a particular machine that operates analogously to specific logic circuits, which themselves could be used to implement the disclosed subject matter.

(53) Example computer readable data storage media for storing such program instructions are shown by reference numerals 8 (memory) and 10 (cache) of the computer system 2 of FIG. 5. The computer system 2 may further include one or more secondary (or tertiary) storage devices (not shown) that could store the program instructions between system reboots. The computer system 2 could also store information on one or more remote servers (not shown), which would also include a computer readable storage medium for storing program instructions as described herein. A further example of a computer readable data storage medium that may be used to store the program instructions would be portable optical storage disks of the type that are conventionally used for commercial software sales, such as compact disk-read only memory (CD-ROM) disks, compact disk-read/write (CD-R/W) disks, and digital versatile disks (DVDs). Examples of such media are shown by reference number 200 in FIG. 10.

(54) The computer readable storage medium can thus be a tangible device that can retain and store instructions for use by an instruction execution device. The computer readable storage medium may be, for example, but is not limited to, an electronic storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any suitable combination of the foregoing. A non-exhaustive list of more specific examples of the computer readable storage medium includes the following: a portable computer diskette, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or Flash memory), a static random access memory (SRAM), a portable compact disc read-only memory (CD-ROM), a digital versatile disk (DVD), a memory stick, a floppy disk, a mechanically encoded device such as punch-cards or raised structures in a groove having instructions recorded thereon, and any suitable combination of the foregoing. A computer readable storage medium, as used herein, is not to be construed as being transitory signals per se, such as radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagating through a waveguide or other transmission media (e.g., light pulses passing through a fiber-optic cable), or electrical signals transmitted through a wire.

(55) Computer readable program code described herein can be downloaded to respective computing/processing devices from a computer readable storage medium or to an external computer or external storage device via a network, for example, the Internet, a local area network, a wide area network and/or a wireless network. The network may include copper transmission cables, optical transmission fibers, wireless transmission, routers, firewalls, switches, gateway computers and/or edge servers. A network adapter card or network interface in each computing/processing device receives computer readable program code from the network and forwards the computer readable program code for storage in a computer readable storage medium within the respective computing/processing device.

(56) Computer readable program code for carrying out operations of the present invention may be assembler instructions, instruction-set-architecture (ISA) instructions, machine instructions, machine dependent instructions, microcode, firmware instructions, state-setting data, or either source code or object code written in any combination of one or more programming languages, including an object oriented programming language such as Smalltalk, C++ or the like, and conventional procedural programming languages, such as the C programming language or similar programming languages. The computer readable program code may execute entirely on the user's computer, partly on the user's computer, as a stand-alone software package, partly on the user's computer and partly on a remote computer or entirely on the remote computer or server. In the latter scenario, the remote computer may be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or the connection may be made to an external computer (for example, through the Internet using an Internet Service Provider). As previously mentioned, in some embodiments, electronic circuitry including, for example, programmable logic circuitry, field-programmable gate arrays (FPGA), or programmable logic arrays (PLA) may execute the computer readable program code by utilizing state information of the computer readable program code to personalize the electronic circuitry, in order to perform aspects of the present invention.

(57) Aspects of the present invention are described herein with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and/or block diagrams, and combinations of blocks in the flowchart illustrations and/or block diagrams, can be implemented by computer readable program code.

(58) The computer readable program code may be provided to a processor of a general purpose computer, special purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions/acts specified in the flowchart and/or block diagram block or blocks. These computer readable program code may also be stored in a computer readable storage medium that can direct a computer, a programmable data processing apparatus, and/or other devices to function in a particular manner, such that the computer readable storage medium having instructions stored therein includes an article of manufacture including instructions which implement aspects of the function/act specified in the flowchart and/or block diagram block or blocks.

(59) The computer readable program code may also be loaded onto a computer, other programmable data processing apparatus, or other device to cause a series of operational steps to be performed on the computer, other programmable apparatus or other device to produce a computer implemented process, such that the instructions which execute on the computer, other programmable apparatus, or other device implement the functions/acts specified in the flowchart and/or block diagram block or blocks.

(60) The flowchart and block diagrams in the Figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of the present invention. In this regard, each block in the flowchart or block diagrams may represent a module, segment, or portion of instructions, which includes one or more executable instructions for implementing the specified logical function(s). In some alternative implementations, the functions noted in the block may occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the block diagrams and/or flowchart illustration, and combinations of blocks in the block diagrams and/or flowchart illustration, can be implemented by special purpose hardware-based systems that perform the specified functions or acts or carry out combinations of special purpose hardware and computer instructions.

(61) Although various example embodiments have been shown and described, it should be apparent that many variations and alternative embodiments could be implemented in accordance with the disclosure. It is understood, therefore, that the invention is not to be in any way limited except in accordance with the spirit of the appended claims and their equivalents.