Depending on how long ago task A was preempted, we may or may not want to dispatch task A on processor 2. If the time was short, there are still instructions, and data still exists, in the cache of processor 1 for task A. Dispatching task A to processor 2 would mean the cache for processor 2 would have to be reloaded as cache misses occur, resulting in reduced performance for the task and the system. In this case, it may be better to dispatch a lower priority task on processor 2 and wait until processor 1 is available for task A.

What we have just described is cache affinity. A given task may have an affinity for a particular processor based on the contents of its cache. Task dispatching in a multiprocessor version of an AS/400 is based on a combination of priority, cache affinity, and another characteristic, eligibility. Eligibility can be used to restrict a task to a subset of the processors. Eligibility is never overridden by the task dispatcher. If all processors for which a task is eligible are running higher-priority tasks, the task is not dispatched.

A task is only dispatched if the processor for which it has cache affinity is available. An exception to this rule is made if not dispatching the task would result in a processor remaining idle or in an excessive number of higher-priority tasks on the TDQ being skipped. A skip threshold based on the number of processors is set by the SLIC for the system. If the number of tasks skipped reaches the threshold, affinity is ignored and the task is assigned to any processor for which it is eligible. If tasks are skipped and the end of the TDQ is reached before a task is assigned to each processor, the skip threshold is dynamically reduced until there are either no unassigned processors or no skipped tasks.

The three fields in the TDE that are used for multiprocessor task dispatching are

•  Eligibility field — This field has one bit for every processor in the system. Setting a bit on in this field indicates that the task is eligible to run on the corresponding processor. If all bits are on, the task is eligible to run on any processor.

•  Active field — This field has one bit for every processor in the system and indicates the processor on which the task is currently active. At most, one bit can be on if the task is running; otherwise, no bits are on.

•  Affinity field — This field has one bit for every processor in the system and indicates the processor on which the task executed most recently.

In addition to the support for multiprocessors just described, the AS/400 can have multiple TDQs. This support was included in the original System/38 to enable dispatching from multiple queues, although it was not used for that purpose. As the number of processors increases to the point where a single TDQ becomes a bottleneck, the dispatching can be accomplished with multiple TDQs.

The current n-way processors use an SMP shared-memory model with all processors operating out of the same memory. In Chapter 12, we look at other SMP models that will be used in future AS/400 systems. All of these are supported by the existing tasking structure.

Asymmetric Multiprocessing

Before leaving this section on multiprocessing, we want to look briefly at the topic of asymmetric multiprocessor (ASMP) systems. In an ASMP system, parts of an operating system, or even different operating systems, run on dedicated processors. The tasking structure in an AS/400 also supports this model of multi-processing.³ An early design for the System/38 implementation included multiple processors, each running a part of the operating system below the MI. The idea was to have one processor dedicated to the database management system, another dedicated to storage management, and so on. This ASMP design used the tasking structure to exchange messages between the processors and to dispatch work. This exact model of multiprocessing, where many operating-system functions are split across multiple processors, was never used in the System/38. A version of this ASMP model, however, was introduced with the AS/400.

---

³We probably shouldn’t talk about this as ASMP. Many “propeller heads” today believe this is old-fashioned technology. So in the following chapters, we talk about these processors as coprocessors or application engines.

---

In Chapter 10, we examine the AS/400’s I/O structure, which was a major change from the original System/38 design. The AS/400 uses multiple processors to execute specific I/O operating system functions. A large system can have hundreds of these processors. We will see that each of these I/O processors has its own operating system. While most of these operating systems are designed specifically to support I/O functions, some of them are beginning to be more general purpose. This design allows other operating systems and the applications written for these operating systems to run under the covers of an AS/400. Thus, it will be possible to have multiples of these application engines in an AS/400 in addition to the main processors.

Dynamic Priority Scheduling

In the previous sections, we simplified the discussion of task dispatching in an AS/400 to make it more understandable. Since the first System/38, numerous additions have been made to the tasking structure to satisfy the requirements for different application environments and system structures. For example, we recognized early on that sometimes the system needed to dynamically adjust the priority of a task during execution. Suppose a task is not getting enough processor time to make progress, or a task has locked some resource in the system for which a higher-priority task is waiting. If the system could temporarily increase or decrease the task priorities, the situations just described could be remedied. We added this capability for the System/38 and early AS/400s.