Talk:Asymmetric multiprocessing/Archive 1

Archive 1

Do all the processors in an ASMP system have to be identical?

Does Asymmetric multiprocessing refer to identical processors asymmetrically sharing the workload, or does it also encompass dissimilar processors working together on the same task? For example, do the SNES and the PlayStation 2 qualify as being asymetrically multiprocessing? --Martin Rudat(T|@|C) 02:02, 23 April 2006 (UTC)

I don't know about the SNES, but IMHO the PS2 and the PS3 would qualify as an asymmetric system. --Pezezin 23:12, 10 May 2006 (UTC)

The PS2 does not qualify as a AMP equipped unit as the Emotion Engine VPUs are actually separate from the CPU. In an AMP system like the PS3, the differentiated cores all make one CPU unit locked to the same clock and contiguous memory space but unable to all process the full set of instructions available, whereas the PS2 is more of a semi SoC setup with a CPU then a dedicated VPU that is directly linked to the GIF (graphics). The VPU and rest of the CPU have completely non-connected memory space within the die, so don't really constitute a processor, and would be addressed more like a PCI-bus-connected device (much like the GPU would be). 37.152.200.88 (talk) 01:10, 11 July 2013 (UTC)

In another thread I mentioned the CDC 6600, in which a single 10 MHz clock drives a 60-bit Central Processor and 10 12-bit peripheral processors; each PP had access to all 12 I/O channels. The operating system runs on the PPs, with the kernel on PP0. I would certainly consider that to be an ASMP Shmuel (Seymour J.) Metz Username:Chatul (talk) 21:48, 15 July 2013 (UTC)

Complete Answer To "What is Asymmetric multiprocessing"

Your question, outlines the answer. All of the above are forms of ASMP and can be defined by its different subsections.

Software ASMP and hardware ASMP G7a (talk) 04:09, 11 February 2008 (UTC)

Complete Answer To "What Does This Article Refer To"

As of now, this page refers to both Asymmetric multiprocessing AND Asymmetric multiprocessors.It is a very confusing topic that I feel should be in one place as

many will come looking for one thing but want the other. In the grand scheme of things, both topics to come together and become the same thing. Its all one idea, broken down into different areas of computing. G7a (talk) 05:09, 11 February 2008 (UTC)

Is it a ASMP system? Or is it a coprocessor?

ASMP is a type of multiprocessing, correct? What is multiprocessing? Multiprocessing is where two or more CPUs are used within a single computer system. So why does the article give an example of a ASMP system as a personal computer with a CPU and a GPU? Are the two performing multiprocessing? I don't think so. So how can it be classified as a ASMP when it isn't performing multiprocessing in the first place? If someone thinks that this scenario does qualify as a multiprocessor and not as a uni-processor system with a coprocessor (the GPU), I would like to see some reliable sources (multiple ones in fact, such claims are a bit dubious) stating this, such as papers from the ACM or the IEEE, or university level textbooks. Rilak (talk) 12:47, 14 September 2008 (UTC)

Yes, ASMP is an early form of multiprocessing, in which a second CPU is added to a computer system that lacks a re-entrant operating system. If there are no objections I will revise the article to make this clear. This will involve removing the references to I/O channels and co-processors. John Sauter (talk) 12:17, 18 September 2010 (UTC)

What about the iPhone?

The article states that there are no ASMP devices being sold today, but I'm pretty sure the iPhone and iPod Touch are both ASMP systems. The main CPU is an ARM-11 chip, and they use an ARM-7 chip at a slower clock speed for things like audio decoding. MaxWinsForever (talk) 04:33, 11 April 2009 (UTC)

Article is wrong to say ASMP processors are old and not commonly used

"Currently there are no consumer level production computers that use asymmetric multiprocessor designs." As others have said, Cell processor, PS2, etc etc, there are many commodity processors that are ASMP, so this quote is wrong. —Preceding unsigned comment added by 69.36.131.254 (talk) 22:44, 1 September 2009 (UTC)

ASMP is from early 1960s

The article states that ASMP was first used in 1970, but there were ASMP machines at universities in 1968 (see [1]) and Burroughs was selling a dual-processor B5000 in 1963 (see [2]). If there are no objections I will edit the article to add this information. John Sauter (talk) 21:39, 14 September 2010 (UTC)

rewrite planned

I am planning to rewrite the article based on ASMP being an early form of multi-processing, and multi-processing being defined as multiple CPUs, all of which use the same instruction set and run user applications. If I hear no objections I will perform this rewrite within a few days, and we can all improve the result. John Sauter (talk) 22:31, 21 September 2010 (UTC)

The rewritten article is posted. It should adequately answer the above concerns about the meaning of the term “Asynchronous Multiprocessing”. John Sauter (talk) 12:45, 24 September 2010 (UTC)

Since the M65MP was SMP, why is it listed with ASMP?

part 1

The MP configuration of the 360/65 was an SMP, as subsequent text in the article notes. Why is it listed as an early example of an ASMP? In fact, the historical development of IBM mainframe operating systems was the opposite of that suggested in the article; IBM supported SMP for OS/360 and for MVS before it offered AP models.

Possibly the IBM 9020 could be considered as an SMP. Shmuel (Seymour J.) Metz Username:Chatul (talk) 19:26, 22 November 2010 (UTC)

The issue is not the hardware but the software. It is unclear from the information I could find whether the M65MP software was ASMP or SMP. Possibly it started out ASMP and gradually evolved towards SMP. I heard a story that M65MP required that all I/O devices have the same address from each CPU. I don't know if that was true, and even if it was, it might not have been true throughout the life of M65MP. I have not been able to locate an on-line copy of the M65MP manuals; if you have paper copies they could answer the ASMP versus SMP question. John Sauter (talk) 14:12, 23 November 2010 (UTC)

The M65MP support in OS/360 had no ASMP support. Yes, it required that the two sides be identical. No, that did not change.

I have dead trees for Machine Check Handler (MCH) and MVT logic, but don't have either broadband or a scanner. The references in OS/360 and successors have links to online copies. The relevant manuals are for the 360/65 and MVT; there's nothing specific to M65MP, except possibly a planning guide. Shmuel (Seymour J.) Metz Username:Chatul (talk) 16:11, 23 November 2010 (UTC)

From what little I have been able to glean from the manuals on bitsaver.org that mention M65MP, it appears that there was some form of “big kernel lock”. I have not been able to determine how much of the kernel that covered. If it covered essentially all of it, that is ASMP, since the kernel would essentially run on only one processor at a time. If it covered very little, that approaches SMP. Do you have any insight on the amount of locking done by M65MP? What about TSS/360 and MTS? The amount of locking might, of course, have changed from release to release. I imagine the operating system for the System/370 model 168 achieved greater efficiency when running on a dual processor by cleverer locking. John Sauter (talk) 22:43, 23 November 2010 (UTC)

The existence of locks is not what makes a system ASMP, but the presence of distinguished processors. In an M65MP the two processors have equal status; either can access peripherals, either can dispatch work and either can process interrupts.

I believe that what you're referring to is the handling of the Set System Mask (SSM) instruction. In OS/360 that instruction is only used with a mask of 00 or FF. The M65MP in multisystem mode deviates from the architecture by causing a program interrupt with interrupt code 18 for an SSM. The interrupt handler does a Test and Set (TS) loop if the mask is 00 and clears the lock flag if the mask is FF, stores the mask into the program old PSW and does an LPSW to simulate the effect of a normal SSM instruction. The net effect is that other than the code in the program interrupt handler, only one CPU can execute disabled code at a time. That didn't have a major effect on performance because OS/360 spent most of its time enabled.

This isn't comparable to a “big kernel lock”, because OS/360 doesn't have the paradigm of kernel code always running with interrupts disabled and most synchronization in OS/360 was done with the ENQ and DEQ SVC's. Shmuel (Seymour J.) Metz Username:Chatul (talk) 23:24, 23 November 2010 (UTC)

I respectfully disagree with your definition of ASMP. As the references in the article to contemporary writings make clear, the difference between ASMP (or master/slave) and SMP was a matter of software, not hardware. Also, there was a gradual progression of software from ASMP to SMP. To use an example I am familiar with, the DEC PDP-10 hardware was capable of SMP, but the early software was ASMP. Perhaps M65MP was closer to SMP than the B5000 MCP or TOPS-10 on the DECsystem-1055, and if so that should be noted in the article. However, the System/360 model 65MP is such a well-known example of multiprocessing that I would hate to eliminate it entirely. John Sauter (talk) 05:06, 24 November 2010 (UTC)

The software is symmetrical. not just the hardware. Neither processor has dedicated capabilities or roles.

• IBM, "MVT Guide" - GC28-6720-4, R21, March 1972
• IBM, "MVT Supervisor PLM" - GY28-6659-7, Program Logic Manual, March 1972
• IBM, "OS I/O Supervisor PLM" - GY28-6616-9, Program Logic Manual, R21.7, April 1973

should make it clear. Shmuel (Seymour J.) Metz Username:Chatul (talk) 16:05, 24 November 2010 (UTC)

(indentation reset for readability)

The IBM manuals you cited are very interesting. Unfortunately they don't say much about the task scheduler in M65MP, but I did find these nuggets in the I/O Supervisor PLM: “(only one CPU executes the I/O supervisor at a time)” and “A CPU does not have access to the other CPU's console, and only one CPU has access to teleprocessing devices.” The fact that the I/O supervisor runs on only one CPU at a time argues for the existence of a large-scale lock. The fact that teleprocessing devices run on only one CPU means that the system as a whole was not completely symmetric. John Sauter (talk) 04:49, 25 November 2010 (UTC)

The dispatcher for M65MP is the MVT Dispatcher, with a bit of extra code to do a shoulder tap (Direct Connect line to other CPU) in order to force dispatching of higher priority work.

The I/O Supervisor ran on both CPU's; it was completely symmetrical. The fact that there was a lock involved did not change that. Programs on both CPU's did Execute Channel Program (EXCP), and IOS ran on the CPU that did the EXCP. Similarly, IOS handled I/O interrupt on the CPU that the channel was attached to. On average it ran 50% on each CPU.

Since you state that the difference between ASMP (or master/slave) and SMP was a matter of software, not hardware, the ability to physically attach I/O equipment to only a single channel does not affect whether it is an SMP. As long as your sysgen matches your physical configuration, the software will work regardless of what is attached to which side. The only constraint is that a device attached to both sides must have the same channel numbers on both sides, although they don't have to all be online. Shmuel (Seymour J.) Metz Username:Chatul (talk) 15:00, 25 November 2010 (UTC)

What would you think of this language? “M65MP was closer to SMP than MCP for the B5000 or TOPS-10 for the DECsystem-1055, since the operating system kernel ran on both processors (though with a “big lock” around the I/O handler) and peripherals could generally be attached to either processor.” with a reference to the I/O supervisor PLM to back up these statements. John Sauter (talk) 03:12, 26 November 2010 (UTC)

I don't believe that the use of a lock is relevant; the software is completely symmetrical. How about

while the software for M65MP was symmetrical, each I/O channel belonged to a single CPU, and an I/O controller attached to only a single channel could not be used if the owning CPU was taken offline.

?

The same was true for MVS before support for channel set switching; an asymmetrical device was lost if the CPU went down. Shmuel (Seymour J.) Metz Username:Chatul (talk) 02:41, 28 November 2010 (UTC)

(resetting the indent level again)

The nature of the locking is the whole difference between ASMP and SMP. On the B5000, the entire kernel was locked. At the Stanford AI lab, a small part of the kernel ran on the second processor, while most of it was aware only of the boot CPU. On M65MP, the I/O supervisor was locked. On today's Linux kernel, there is fine-grained locking which allows the kernel to run efficiently on a multiprocessor. Thus, there is a progression from ASMP to SMP which has nothing to do with the hardware. John Sauter (talk) 04:49, 28 November 2010 (UTC)

Presumably by that you mean that, even if there's a giant lock around the kernel, any processor can run in kernel mode, and all kernel functions can run on any processor, that's SMP? The description of the B5000 sounds like SMP with a giant lock, as does M65MP; the Stanford AI system sounds like ASMP. Guy Harris (talk) 04:57, 28 November 2010 (UTC)

No, that's not what I meant. An extreme case of ASMP involves a lock around the whole kernel, so that it runs on only one processor. In the B5000 the kernel was forced to run on processor A only, but that is only one way to implement ASMP. Another way is to have a processor that wishes to enter the kernel wait on a lock until no other processor is executing the kernel. The kernel will run on any processor, but only on one processor at a time. Early versions of the Linux kernel did this, using the “big kernel lock”. The hardware may be fully symmetric, but if only one processor can run the kernel at a time, that is ASMP.

A fully SMP system is one like today's Linux kernel, in which fine-grained locking is used to prevent destructive interference between processors, but many processors can be executing the kernel at the same time. M65MP was an intermediate system, locking the whole I/O supervisor but not the whole kernel. I imagine other sections were interlocked as well, such as memory allocation, but I have not been able to find a citeable reference. John Sauter (talk) 05:13, 28 November 2010 (UTC)

In what way is a system in which no individual processor is special, but only one processor can be in the kernel at any given time, "asymmetric"? Where's the asymmetry? I view a system where any processor can take on a given role (running user code, running kernel code on behalf of a system call, handling I/O interrupts, etc.) as symmetrical, and I doubt I'm the only one to do so. Guy Harris (talk) 09:49, 28 November 2010 (UTC)

The term “Asymmetric Multiprocessing” is a technical term from the 1960s and 1970s. It evolved from the realization that an operating system which handled multiple CPUs efficiently and reliably was hard. In the article the first reference is to a 1979 survey paper called “Introduction to Multiprocessing”. Software is covered in chapter five, which contains the following paragraph:

“Multiprocessing was a stated development goal at DIGITAL as early as 1963. Multiprocessing as a master/slave relationship was first made available to DIGITAL customers with TOPS-10 release 5.04 (for the KA10) and TOPS-10 releases 5.07 and 6.03 (for the KI10). A symmetric multiprocessor, with equal responsibility among the processors, has been field-tested but is not yet commercially available.”

That quote says nothing about locks causing a symmetrical system to be an ASMP. Shmuel (Seymour J.) Metz Username:Chatul (talk) 15:13, 28 November 2010 (UTC)

Exactly. "Master-slave" is definitely asymmetrical, but if you have N > 1 processors, and none of those processors are permanently assigned, for example, "master" or "slave" roles, that's different - even if, for example, a giant lock means that, at any given time, only one of those processors, whichever of those processors it might be, can be running kernel-mode code. In the latter case, all processors have equal responsibility. Guy Harris (talk) 19:45, 28 November 2010 (UTC)

The survey paper uses the terms “master/slave” and “hierarchical multiprocessor”, but the term “Asymmetric Multiprocessing” was also used to contrast with the long-term goal, which was “Symmetric Multiprocessing”. The following sentence is from later in chapter 5: “A symmetric multiprocessor (SMP) system requires only new software; the hardware is essentially unchanged.” John Sauter (talk) 14:40, 28 November 2010 (UTC)

That sentence says nothing about locks causing a symmetrical system to be an ASMP, and is not true in general; if I/O equipment is attached to only one processor, there is no way that the software can make it symmetric. Shmuel (Seymour J.) Metz Username:Chatul (talk) 15:13, 28 November 2010 (UTC)

The case with the B5000 is not at all similar to the case with M65MP_. On the B5000, Processor B could not run kernel code at all; there was no lock and no need of a lock. On M65MP either processor could run any OS code, and the disabled sections were short. Shmuel (Seymour J.) Metz Username:Chatul (talk) 15:13, 28 November 2010 (UTC)

Notes for Talk:#Since the M65MP was SMP, why is it listed with ASMP?

part 2

(I have divided the topic into parts for ease of editing.)

Imagine an IBM System/360 model 65 with two processors running M65MP. As I understand it, each processor has its own console, and can share devices connected through channels by attaching them to channels on both CPUs using the two-channel switch feature of the control units. The “ideal” system has all devices (except its consoles) connected this way. However, it is also possible to connect some devices to only one channel. In this case the system will discover at IPL time that some devices are not accessible from one channel, and mark them so that an attempt to do I/O on them from the “wrong” CPU will cause the other CPU to be notified that it must do the I/O.

In an extreme case, you could have no I/O devices that were accessible from both CPUs, provided every I/O device had a unique address. Doing this doesn't make M65MP any more or less symmetric—the software is the same, just the I/O configuration has changed. John Sauter (talk) 21:08, 28 November 2010 (UTC)

Correct. In practice most I/O controllers had 2-channel switches. Also, an IBM 2914 switch would allow manually transferring communications equipment from one side to the other, with some disruption. 13:00, 29 November 2010 (UTC)

On the B-5000, there was a hardware-implemented lock which forced the kernel to run on only one processor. On other systems, that lock was implemented in software, but there is no important difference. Going one step further and allowing the kernel to run on either processor, but only on one at a time, is only a small step along the road to full SMP. M65MP was much further along that road, since it locked only sections of the kernel rather than all of it. However, note that M65MP used only a single lock. If one processor was in the I/O supervisor the other could not do an unrelated function that required serialization, such as memory allocation. John Sauter (talk) 21:08, 28 November 2010 (UTC)

If you want to draw a distinction between MP systems where there exists a lock that guards multiple unrelated sections of code, or several unrelated data structures, and MP systems where a lock held around one part of the system doesn't block other processors from executing in unrelated parts of the system, that's reasonable. However, that's different from the distinction between systems where particular processors have particular roles assigned to them; I'd call that asymmetric, but I wouldn't call systems that don't assign particular processors particular roles "asymmetric", as there is symmetry between the processors. Perhaps "coarse-grained SMP" vs. "fine-grained SMP"? Guy Harris (talk) 22:04, 28 November 2010 (UTC)

It is certainly true that there are degrees of locking, and I think “coarse-grained” and “fine-grained” are good descriptive terms. If I were creating terminology today, I would call the earliest multiprocessors (such as the B-5000) “master/slave” but that word wasn't politically correct in the 1960s and 1970s. The notion of locking as a way to prevent destructive interference was well-known in database software, but the term was not yet current in operating systems. The goal from the earliest days was that the operating system would run equally on all processors. That was called symmetric multiprocessing, and asymmetric multiprocessing simply meant “not symmetric multiprocessing”. John Sauter (talk) 03:56, 29 November 2010 (UTC)

Locking does not introduce any asymmetry among the processors. Consider another example; the OS has a list of dispatchable units waiting for work and several processors become available concurrently. Each processor attempts to remove the first element from the dispatch queue. Only the first processor succeeds. Would you call the OS an ASMP because of that behavior? 13:00, 29 November 2010 (UTC)

Where a computer falls along the line between completely ASMP (the B-5000) and completely SMP (modern Linux kernels) depends on how well the kernel makes good use of all the processors. In the example you cite, we learn only that all processors run the task dispatcher, which puts the kernel well away from the ASMP end of the scale, but more details would be needed to know how close to full SMP it is. Locking is necessary in any multiprocessor; the Linux kernel has many locks and they can he held by different processors at the same time. John Sauter (talk) 04:46, 30 November 2010 (UTC)

The B5000 did not have a lock, hardware or software. Processor A was a B5280 and processor B was a B5281. The B5281 could not control I/O or process interrupts. Processor A handled all interrupts, even synchronous interrupts for Processor B. As to master/slave not being politically correct in the 1960's and 1970's, the term was indeed used, not only for processors but also for processor states, e.g., the GE 625 had an instruction called Transfer and Set Slave.

Perhaps I am mistaken about the offensiveness of the word “slave” during the civil rights struggles. Perhaps some people were more sensitive than others. I regard the fact that the B-5000's processor B would not enter the kernel but instead interrupted processor A as the hardware equivalent of an exclusion lock around the whole kernel. Consider that the net effect was the same: the kernel ran on only one processor at a time, and so didn't need to do any further locking to prevent simultaneous modifications to (and thereby destruction of) kernel data structures. The B-5000's implementation of multiprocessing was well-known in the industry, and perhaps it (and not political correctness) was the inspiration for calling early (non-SMP) multiprocessors Asymmetric Multiprocessing. John Sauter (talk) 04:46, 30 November 2010 (UTC)

You could consider the lack of any physical hardware connection between processor B and anything that would provoke an entry into the kernel (did the B5000 even have a notion of "kernel mode"/"supervisor state"/etc. and "user mode"/"problem state"/etc.?) as equivalent to having a giant lock around the kernel that processor A grabs before processor B even gets anywhere near that code and that it never ever releases. That's not exactly the same as a giant lock around the kernel that either processor can grab and that's released as soon as the kernel code returns to userland; both of them mean that you can't have parallelism in the kernel - one processor couldn't be spending CPU time on one kernel operation while another processor spends its own CPU time on another kernel operation, so neither of them allow the kernel to make much use of the fact that you have multiple processors (although you can, at least, have one processor spending CPU time on a kernel operation while another processor is spending its CPU time doing userland work) - but only one of them, the first, assigns a particular processor any particular role (the role of running code that controls I/O operations or handles interrupts). Guy Harris (talk) 07:20, 30 November 2010 (UTC)

Yes, the B-5000 had “normal state” and “control state”. Processor B could not enter control state. John Sauter (talk) 13:10, 30 November 2010 (UTC)

M65MP locking

As for M65MP, the SSM lock was not its only serialization mechanism; it also used ENQ/DEQ, roughly comparable to semaphores. 13:00, 29 November 2010 (UTC)

But didn't M65MP only prevent two processors from running with the interrupt mask set to 0 at the same time? There might have been a form of ENQ that disabled interrupts (perhaps “system must complete”) but surely not all forms disabled interrupts. John Sauter (talk) 04:46, 30 November 2010 (UTC)

ENQ only disabled interrupts briefly. When ENQ could not grant immediate access to the resource, then depending on the specified options it either returned to the caller or added the task to the list of tasks waiting for the resource amd called the Dispatcher to look for other work. If the resource was available then ENQ returned control with the callers original system mask, normally FF. SMC didn't change that.

I realize that the CS paradigm describes a kernel that runs disabled and can't use normal system services, but OS/360 was not built on that model. Most of the privileged code runs with interrupts enabled and can call any SVC routine. The use of disabled code is rare. Shmuel (Seymour J.) Metz Username:Chatul (talk) 12:23, 30 November 2010 (UTC)

Did M65MP do anything to prevent two processors from accessing the same resource simultaneously, other than making sure that both processors could not be running the kernel with interrupts disabled at the same time? If not, then something like memory allocation would have to have been done with interrupts disabled. John Sauter (talk) 13:17, 30 November 2010 (UTC)

If a task did an exclusive ENQ on a resource, that locked out all other tasks. A task could only run on one CPU at a time. If all use of a data structure is protected by ENQ then there is no need to disable interrupts, except for the small amount of code in ENQ/DEQ that runs disabled.

Aha, so ENQ would disable interrupts long enough to flag the resource as being in use. Another task running on another processor which tried to do an ENQ on the same resource at the same time would wait for the first task to enable interrupts, then discover that the resource was in use. That makes sense, but it implies that ENQ was very slow, even when the resource was not in use, because of the need to disable interrupts. When ENQ was done in problem state, did it use an SVC to do the interrupt disable and resource checking? If I am understanding the manual you referenced below, the test for an available resource could have been done using an atomic instruction. This might even have worked in M65MP. John Sauter (talk) 14:02, 30 November 2010 (UTC)

MVT spent little time with interrupts disabled, so there wan't much performance impact from two task doing an ENQ at the same time. ENQ and DEQ were macros that expanded into SVC instructions; the only difference between a privileged use and an unprivileged use were what options were allowed.

The CS and CDS instructions didn't come along until the S/370, and TS only toggled a single bit, so there was no way to use an atomic instruction to update the queue. Shmuel (Seymour J.) Metz Username:Chatul (talk) 15:37, 1 December 2010 (UTC)

To be sure, but Test and Set could have been used to guard the queue-handling code, in the form of a spinlock. That would likely have been more efficient than SSM, which caused an interrupt. However, if interrupt-level code could also manipulate the lists, you would also have had to disable interrupts, making the TS instruction unnecessary. John Sauter (talk) 20:31, 1 December 2010 (UTC)

This whole thread made me realize that I need to add a few more manuals to my master list. In particular, I need to track down my dead tree copy of OS/360 Supervisor Services and Macro Instructions and also to check whether bitsavers has it online. The description of ENQ/DEQ is there. In the meantime, an archaic version is available in IBM (April, 1966). IBM System/360 Operating System Control Program Services (PDF). C28-654l-l. {{cite book}}: Check date values in: |date= (help); Unknown parameter |separator= ignored (help); the interface changed shortly after that manual, so don't read too much into it. Shmuel (Seymour J.) Metz Username:Chatul (talk) 13:35, 30 November 2010 (UTC)

I agree that more information would help the discussion, and I am also personally interested in the details. If there isn't a copy on bitsavers, perhaps you could scan your copy and contribute it. John Sauter (talk) 14:02, 30 November 2010 (UTC)

The earliest copy that I could find online was IBM (September 1983). OS/VS2 MVS Supervisor Services and Macro Instructions (PDF). Fifth Edition (September 1983). GC28-0683-3. {{cite book}}: Unknown parameter |separator= ignored (help) Includes Selectable Units:

• Supervisor Performance #2 VS2.03.807
• IBM 3800 Printing Subsystem VS2.03.810
• System Security Support 5752-832
• Dumping Improvements 5752-833

I'm still looking for my dead tree, but the only major difference in ENQ/DEQ is that SMC=SYSTEM no longer exists. Or did that change come later? Shmuel (Seymour J.) Metz Username:Chatul (talk) 01:13, 1 December 2010 (UTC)

I couldn't find any reference to SMC in the ENQ description of the manual you cited. Looking through that description, “SYSTEMS” tickled an old memory: I am pretty sure it was added after the switch from MVT to VS/2. John Sauter (talk) 15:06, 1 December 2010 (UTC)

Depending on the release, that would be in the System Programmer's Guide or in Systems Programming Library: Supervisor. Shmuel (Seymour J.) Metz Username:Chatul (talk) 15:37, 1 December 2010 (UTC)

question about exits

Imagine this scenario on M65MP: a task is running on processor A and issues an I/O request for a device that is accessible only on processor B. The I/O supervisor asks processor B to issue the Start I/O instruction. When the I/O operation completes, processor B is interrupted and finds that the task has an exit routine for the I/O operation.

I didn't see anything in the I/O supervisor PLM about processor B asking processor A to run that exit, but if it doesn't, then the task will be running on both processor A (the main-line code) and on processor B (the exit routine). That is what you would expect on a fully SMP system, but on M65MP I suspect it would open up a large can of worms. Applications weren't coded to expect this behavior, and the kernel would need defense against the mainline and the task making kernel requests at the same time. Therefore, I suspect that exits for a task are run on the processor which is executing that task, even if the event that caused the exit to be run happened on the other processor. John Sauter (talk) 15:06, 1 December 2010 (UTC)

What kind of exit are you talking about? I/O appendages run as extensions of the I/O supervisor, not as part of the task; they are always handled by the CPU taking the interrupt or I/O request. At the application level, exits run under an Interrupt Request Block. Requests to schedule an IRB go on a global queue, which the dispatcher services. When IRB is activated, other work on the TCB is suspended. See the MVT Supervisor PLM for details of RB processing. Also see "exit effector" in the same manual. Shmuel (Seymour J.) Metz Username:Chatul (talk) 15:37, 1 December 2010 (UTC)

I've never been familiar with OS/360 application programming; I saw the reference to exits in the description of ENQ and DEQ. The implication was that they were something that could happen asynchronously, such as at the completion of an I/O operation. Your explanation that application-level exits run as part of the task answered my question. Apparently, either processor's I/O appendage can enqueue an IRB, and the dispatcher will schedule it as part of the task. Thanks for answering my question. John Sauter (talk) 20:39, 1 December 2010 (UTC)

To clarify, a DCB for EXCP can specify multiple types of I/O appendages. I would expect only the Channel End and PCI appendages to schedule an IRB. Shmuel (Seymour J.) Metz Username:Chatul (talk) 21:11, 1 December 2010 (UTC)

References

What about MTS?

In a note from 22:43 23 November 2010 John Sauter asked "What about TSS and MTS?" I can't speak about TSS, but MTS was SMP. The supervisor (UMMPS) ran on either or both CPUs of the S/360-67. Supervisor locks were small and were used to protect individual common data structures that might be accessed simultaneously from either CPU. Individual tasks (jobs, processes) would only execute on one processor at a time. Time Sharing Supervisor Programs by Mike Alexander (May 1971) has information on MTS, TSS, CP/67, and Multics which might be interesting. Jeff Ogden (talk) 16:12, 22 December 2010 (UTC)

This is good information for the article. If you don't object, or add it yourself, I will add it. John Sauter (talk) 16:47, 22 December 2010 (UTC)

No objection. Jeff Ogden (talk) 17:17, 22 December 2010 (UTC)

multi-dimensional characterization

I think there are at least two separate axes needed to properly categorize MP systems composed of otherwise-(mostly or completely)-interchangeable processors, one axis indicating to what extent particular processors are assigned particular roles (with one extreme perhaps being "all kernel code, including interrupt handlers, runs on processor A" and the other extreme being "anything can run on any processor"), and another axis indicating how coarse the locking is (from "only one processor at a time can execute in the kernel" to the extreme case of "every field of every data structure has its own lock"). Most modern OSes are closer to the second end in both cases (although not necessarily all the way to that end - I have the impression at least some OSes have a processor which is the first to start up during boot, starting the others up as soon as there's enough stuff done that they won't step on its toes, and one that's last to shut down, waiting for the others to halt before it does the final stages of halting, and I doubt any go to quite that extreme of fine-grained locking. You might be able to combine those two coordinates into a single figure of merit for "how well the kernel makes good use of all the processors", but the resulting figure of merit doesn't just describe where the system falls on the line between completely ASMP and completely SMP (that's more the first axis in my taxonomy). Guy Harris (talk) 07:02, 30 November 2010 (UTC)

There's also the issue of the extent to which the OS uses Atomic instructions, e.g., CS on S/370, to avoid the need for locking. Shmuel (Seymour J.) Metz Username:Chatul (talk) 13:22, 30 November 2010 (UTC)

I regard atomic instructions as very fine-grained locks, implemented in hardware. This makes an interesting contrast with the B-5000's processor B, which implemented a very coarse-grained lock in hardware. John Sauter (talk) 13:44, 30 November 2010 (UTC)

For purposes of an encyclopedia article, I think some simplification is needed, though not so much that an expert in the field is offended. The notion that the kernel makes “good use” of all processors is intuitive, and suggests a line from “not very” to “very” good use. Obviously this is a summary based on the details of how the kernel is implemented. I have suggested locking as one contributor to that measure, and your suggestion that whether or not processors have different roles, and how they differ, is a good one. There are, as you suggest, other considerations as well, such as the use of atomic instructions and the symmetry of the connection between the various CPUs and main memory: on the System/360 model 65 memory access time depended on the distance between the memory box and the particular CPU, which meant that some software would run faster in one CPU than in the other, depending on where it was loaded into memory.

However, to make the encyclopedia article accessible to the non-expert, the experts need to simplify and summarize. The details can be discussed on the talk page, referenced by footnotes, or even be written as separate, specialized articles. I don't think that simply describing a multiprocessor as “ASMP” or “SMP” would be sufficient; people reading the article need more than that. I do think that giving a vague “more or less” characterization is enough, provided some details are given to justify the judgment. John Sauter (talk) 13:44, 30 November 2010 (UTC)

CDC 6700

A good example of an ASMP would be the CDC 6700; it had one very fast central processor, one moderately fast central processor and 10 peripheral processor with a different instruction repertoire and word size from the central processors. Shmuel (Seymour J.) Metz Username:Chatul (talk) 16:05, 24 November 2010 (UTC)

I am not very familiar with the CDC 6700. Did the very fast and moderately fast central processors share main memory? Was the operating system software able to reschedule a task which had been running on one of the processors to the other? If one of the processors failed, could the system run in a degraded mode using just the other? John Sauter (talk) 04:49, 25 November 2010 (UTC)

Each PP had its own 4 Ki word memory, but there was only one central memory. The OS could dispatched work to either CP. If it took one CP down then it could run all of the work on the other. Shmuel (Seymour J.) Metz Username:Chatul (talk) 14:34, 25 November 2010 (UTC)

I think the 6500 and 6700 should be added to the article, but I have not been able to find anything on-line about the capabilities of the software. I see from the hardware manual that the two main processors shared main memory. John Sauter (talk) 03:14, 26 November 2010 (UTC)

The central processors on the 6500 were fully symmetric. On the 6700 the only difference was speed. The justification for calling it an ASMP is that the PP word size and instruction repertoire were totally different between CP and PP, but that applies to all of the CDC 6x00 and 7x00 machines. Shmuel (Seymour J.) Metz Username:Chatul (talk) 18:20, 26 November 2010 (UTC)

I don't consider the PPUs central processors because user applications could not be rescheduled onto them. They were more like the channels of System/360. For the CDC 6500 and 6700, the difference between ASMP and SMP was the operating system software, and I have not been able to learn anything about it. Was it like M65MP, which let the kernel run on both CPUs but with locking to prevent conflict, or was it like the B5000, where the kernel could run on only one CPU? John Sauter (talk) 13:45, 27 November 2010 (UTC)

If you don't consider the peripheral processors relevant to the classifiction then there is no basis for calling the 6500 an ASMP.

The peripheral processors were not remotely similar to I/O channels. The central processors did not control the peripheral processors; communication was strictly by software convention. Each peripheral processor had full access to central memory, all cetral processors and all I/O channels.

The operating system did not run on the central processors; it ran on the peripheral processors, at least through the early 1970's. The central processors were essentially slaves; they had no access to I/O. In the CDC operating system code in PP0 would periodically inspect a location in the storage of the active job, looking for an OS request. PP0 parceled out work to the other peripheral processors as necessary. Shmuel (Seymour J.) Metz Username:Chatul (talk) 03:03, 28 November 2010 (UTC)

(resetting indentation for readability)

Perhaps I understand even less about the CDC 6000 series than I thought. When the user writes an application program in FORTRAN, isn't it the case that the arithmetic and logic statements are executed on the main processor or processors? If so, when the FORTRAN program executed an I/O statement, and PP0 assigned the request to a peripheral processor, would a different job be scheduled to run on the main processor while the I/O was being done? And if that is the case, on a computer with two CPUs, could a job that was ready to run be scheduled on the second CPU, even if it had previously run on the first, and vice-versa?

It seems to me that the organization of the CDC 6500 and 6700 is different enough from the other multiprocessors listed that the terms ASMP and SMP do not really apply to them. John Sauter (talk) 05:03, 28 November 2010 (UTC)

If a program does a FORTRAN I/O, all of the processing of data lists and formats is done in a central processor. There is never a guaranty that a job will only execute on one CP. When the FORTRAN library is ready to do an I/O, it calls an OS service called Circular I/O (CIO). When PP0 sees the CIO request it allocates a PP to handle the I/O. Depending on the details, the FORTRAN library might block waiting for the I/O to progress, in which case PP0 could assign the CP to another job. If the PP, channel and I/O device can keep up with the FORTRAN program, then it might retain the use of a central processor. Even then, however, PP0 could preempt it if it needed to run a higher priority job or if it was doing time slicing. The only asymmetries are those between the CP's and the PP's, the performance difference between the CP's of a 6700 and the dedicated role of PP0. Shmuel (Seymour J.) Metz Username:Chatul (talk) 16:05, 28 November 2010 (UTC)

Since the operating system does not run on the main CPU(s), the terms SMP and ASMP are not really applicable to this system, even though it is a multiprocessor. John Sauter (talk) 21:10, 28 November 2010 (UTC)

IBM 9020

Another ASMP system is the IBM 9020, where the different processors had different roles. See Blakeney, G. R.; Cudney, L. F.; Eickhorn, C. R. (1967). "An application-oriented multiprocessing system, Part II: Design characteristics of the 9020 system". IBM Systems Journal (Number 2). IBM: 80. doi:10.1147/sj.62.0080. ISSN 0018-8670. {{cite journal}}: |issue= has extra text (help); Unknown parameter |Volume= ignored (|volume= suggested) (help) Shmuel (Seymour J.) Metz Username:Chatul (talk) 16:05, 24 November 2010 (UTC)

If the processors had different roles, I wonder if they could be properly called a multiprocessor? If computers cooperate but do not share main memory, that is a multisystem, not a multiprocessor. John Sauter (talk) 04:49, 25 November 2010 (UTC)

My recollection is that the I/O Elements of a 9020 did share memory with the larger boxes. Shmuel (Seymour J.) Metz Username:Chatul (talk) 15:01, 25 November 2010 (UTC)

Is there a citeable reference for this? Statements in Wikipedia articles need to be backed up with good references. The IBM Systems Journal citation that you used above certainly qualifies as a good reference, but I cannot read it. John Sauter (talk) 03:18, 26 November 2010 (UTC)

expert attention request?

Someone added a request for attention from an expert to the article, but did not add any information to the talk page about the need. As can be seen from the other topics on this talk page, there has been plenty of attention from experts already. Might the request have to do with the recently-added stubs about multiprocessor support by certain operating systems?

Actually, come to think of it, I am not even sure what “non-identical CPUs” means. Does being unable to access the I/O channels make a second CPU non-identical to the first? If the second CPU has a different instruction set from the first, does that make it non-identical? If so, the B5000's processor B qualifies on both counts, since it could not do I/O and could not enter control state. John Sauter (talk) 03:24, 3 September 2011 (UTC)

The added section on the support of non-identical CPUs by various operating systems does not contribute to the article, since it does not provide any information (only a request for information) and such support has nothing to do with asymmetric multiprocessing anyway. If there are no objections I will revert the addition of that section. John Sauter (talk) 13:55, 7 September 2011 (UTC)

Having heard no objections, I have reverted the September 2 edits. John Sauter (talk) 11:38, 10 September 2011 (UTC)

Multics - ASMP or SMP?

part 1

The reference for the claim "Details are scarce, but it appears that Multics would today be called an asymmetric multiprocessing system, because a user program could run on only one CPU." says

Each CPU in a Multics system has identical access to the physical memory. Each CPU has a DSBR pointing to the descriptor segment of the process it is currently running. (A process can only run on one CPU at a time.) Multiple processes can share segments, and two processes on different CPUs can interleave memory accesses by machine instructions arbitrarily. A process cannot tell if some other process is also accessing a segment. If processes share read/write data, they must use the appropriate CPU instructions to coordinate access, in order to avoid overwriting each others' results. The CPU provides instructions such as aos (add one to storage) and stacq (store A conditional on Q) that use the read-alter-rewrite function of the memory controllers to perform atomic operations. It is up to the coordinating programs to establish locking conventions and use these facilities correctly.

MP-safety is a difficult property to ensure, even more difficult than thread-safety. Most Multics users did not have to learn this discipline, because read/write sharing of data by application programs was rare. This was due in part to the high cost of Multics processes: each logged in user had one process at a time.

Multics system programmers working on the supervisor, on the other hand, worked in an environment in which many kinds of data were shared and had to be protected by locking and access conventions. Ring 0 of a Multics process contained multiple shared databases that needed protection. These protections and access conventions were created as a layer of usage convention on top of the execution environment provided by the hardware and PL/I language.

I don't see anything in there that says "a user program could run on only one CPU". I see something in there that says "each logged in user had one process at a time", but that's not at all the same thing; that just says that, when you log in, you get a process to run your login session (a command, in Multics, was run as a subroutine call, rather than as a UN*X-style fork-and-exec or a Win32/Win64-style CreateProcess, both of which run a program in a new process). That section seems to imply that there's no CPU that's special, so that sounds like SMP - and possibly not "giant lock" SMP, if different pieces of shared data have different locks protecting them. Guy Harris (talk) 05:09, 9 October 2011 (UTC)

As you quoted, when you login you get one process, and (from the first paragraph, in parentheses) a process can run on only one CPU at a time. That limitation causes Multics to fall short of SMP by today's standards, which encourages use of multiple CPUs by providing a login with many threads of execution, and spreading them across the CPUs. A programmer writing for a modern SMP system is forced to think about MP safety even if he is doing something as simple as forking a computation task from his GUI. John Sauter (talk) 14:35, 12 October 2011 (UTC)

That's not an issue of asymmetry - as far as I know, none of the CPUs in Multics were "special" in the sense of being the only CPU that could run ring 0 code or being the only CPU that could initiate I/O; that's an issue of the number of threads of control available in a user session. Multics was a multi-user system, and different users could have their sessions run on different CPUs (there's no indication of whether a given process is permanently assigned to a CPU; I suspect not). There may be a term for systems where there are not a lot of processes per session, and where no CPUs have special roles, but that term doesn't involve the word "asymmetric", given that no CPUs have special roles. Guy Harris (talk) 17:00, 12 October 2011 (UTC)

Hmmm. we have had this discussion already—ASMP and SMP are terms of art in computer architecture. There is a progression from very primitive multiprocessors like the Burroughs B5000 to modern SMP systems. That progression involves both hardware and software: even after the hardware supports SMP, until the software does the system as a whole is still ASMP until it reaches SMP. Let us imagine that we could run today's Linux kernel on a multiprocessor that formerly ran Multics. Even if the Linux system were fully SMP, that wouldn't make Multics SMP. John Sauter (talk) 12:30, 13 October 2011 (UTC)

May I please see a citation for your assertion that ASMP and SMP are terms of art rather than terms that have something to do with symmetry? If a system where all processors are equivalent in hardware, and where the operating system doesn't assign special roles to any of the processors, I fail to see any lack of symmetry between the processors, so it's not "asymmetric" in the dictionary sense.

As for a "progression", that implies a one-dimensional scale. Whether a system that has something that could be considered "processes" supports multiple processes per user session, or supports multiple preemptively-scheduled threads of control per process, is orthogonal to the form of multiprocessing. A uniprocessor system, or a multiprocessor system with only one processor running kernel code, or a system where any processor can run kernel code but there's a giant lock around the kernel, can support multiple processes per user session (and many have), and can even usefully support multiple preemptively-scheduled threads of control per process. The fact that Multics didn't support multiple processes per user session, or multiple preemptively-scheduled threads of control per process, has nothing to do with whether it can make full use of multiple processors; it was a multi-user system, and multiple processes could be making ring 0 calls at the same time. The reference states

Multics system programmers working on the supervisor, on the other hand, worked in an environment in which many kinds of data were shared and had to be protected by locking and access conventions. Ring 0 of a Multics process contained multiple shared databases that needed protection. These protections and access conventions were created as a layer of usage convention on top of the execution environment provided by the hardware and PL/I language.

which at least suggests that Multics had something finer-grained than a giant lock around ring 0, and indicates that there was no designated "ring 0 CPU". Guy Harris (talk) 18:07, 13 October 2011 (UTC)

part 2

(I have divided the discussion into parts for ease of editing.)

The historical references in the main article do a good job of describing multiprocessing as it evolved, and the terms used for it during that evolution. See particularly reference 1: Introduction to Multiprocessing, written in 1979. Chapter 5 describes the DECsystem-10, which was moving towards SMP without any change in the hardware: “A symmetric multiprocessor (SMP) system requires only new software; the hardware is essentially unchanged.” This reference uses “master/slave” rather than “asymmetric“ but the meaning is clear.

Yes, “progression” implies a one-dimensional scale, and the advances needed to take the original multiprocessors all the way to today's SMP were along several fronts, and thus better characterized as multidimensional. However, as I argued previously, encyclopedia articles need to simplify the details to reach a general audience, and simplifying the progression of multiprocessor support into a single dimension, which approximately tracks the historical advance of software technology, seems reasonable.

Multics had two limitations which, together, placed it firmly short of today's standard for SMP. One was the limitation of one process per job, and the other was the requirement that a process could run on only a single CPU. The combination of these two limitations meant that a job could run on only a single CPU. By today's standards, making “full use of multiple processors” includes letting an unprivleged user application spread its computation across all the CPUs, and Multics didn't do that. Now, perhaps it is unfair to judge Multics by today's standards, but I feel that an encyclopedia article written for today's general audience needs to use today's standards for comparison. John Sauter (talk) 13:28, 15 October 2011 (UTC)

If there is a useful "single dimension" to use in a simplified description of the development of MP, it's not "degree of symmetry", as once you don't have a master/slave system, and all processors have equal roles (except perhaps during startup and shutdown), you've achieved complete symmetry. If you ignore the transition from master/slave to a symmetric system, the "single dimension" is how fine-grained the locking is - but that ignores the transition in question. I don't think trying to condense that to a single dimension is helpful to the general reader; I think it omits critical details.

And "letting an unprivileged user application spread its computation across all the CPUs" is more important on single-user systems than multi-user systems; on a multi-user system, such as Multics, the fact that one application can't use multiple processors doesn't mean the processors other than the one that application happens to be running on at any given time is just sitting idle - other users' applications can be running on them. Again, omitting that historical context leaves out useful information; trying to stuff all this into the modern model of "multi-core applications" is a bit of a recentism. Guy Harris (talk) 19:06, 15 October 2011 (UTC)

While I agree with all that you have said above, it is not clear to me how the article should be changed. Currently it takes “asymmetric multiprocessing” as an obsolete computer science term, explains why it was invented, and lists some examples. Adding more historical context would certainly be a good idea, but citable references are hard to find. Expanding the description of multiprocessing would also be good, as long as we don't drown the general reader in details. Perhaps we should have more words about fine-grain locking and forcing the application programmer to confront MP issues whenever he does a fork. That latter was a significant change in the way applications worked, and I'm not sure all programmers are accustomed to it yet. John Sauter (talk) 02:32, 16 October 2011 (UTC)

We should, in the introductory paragraph, note that in ASMP systems one (or more, if any systems with more than two processors gave special roles to more than one of them) processors have special roles, e.g. are the only processor capable of performing I/O operations, or are the only ones that perform low-level ("kernel", etc.) operating system functions. Then we remove from the article all systems that aren't ASMP systems in that sense; if that shrinks the ASMP page down to a stub, the discussion of ASMP is probably then best moved to the multiprocessing page. (Yes, this means that "ASMP" is Boolean - either a system is asymmetrical or it isn't, so a system isn't "closer to ASMP than SMP".)

All discussion of systems without "special" processors should be moved to the SMP page, with the details about locking also put on one of those pages. (ccNUMA systems have at least some of the same issues as SMP systems, especially if the systems have more than one level of hierarchy, e.g. a system where you have N-processor nodes, for some value of N, with uniform memory access to the node's memory by all processors, and then non-uniform access by a node to other nodes' memory; each node works like an SMP system; I think at least some ccNUMA systems worked like that. However, I suspect that doesn't mean that the SMP issues should be moved to the MP page, given that the NUMA page says "NUMA architectures logically follow in scaling from symmetric multiprocessing (SMP) architectures".)

The discussion of MP issues being exposed to application programmers would also go into the SMP page, and would be separate from the discussion of locking in the system code that deals with shared data structures. The issues exposed by forks and by threads might also be discussed separately; note that, with preemptively-scheduled processes and threads, most if not all of those issues exist on uniprocessor systems, although the likelihood of a race condition is lower, as you'd need to be preempted in the wrong place. Guy Harris (talk) 09:25, 16 October 2011 (UTC)

Preemptive interrupts cause a different set of nasty issues from multiprocessing, such as nested locks. Also, I am not sure how to characterize the IBM System/370 model 168, which supported two ways of attaching a second processor: with or without access to the channels. Nevertheless, I agree with your reorganization plan. If you will start it I will help. John Sauter (talk) 12:32, 16 October 2011 (UTC)

ARM big.LITTLE architecture

Arm's big.LITTLE architecture (which pairs a low-power core with a high-performance core) may mark a return to AMP in the 2010s, with the new goal maximising efficiency (generally with battery-powered devices in mind). Although described by ARM as 'heterogeneous multiprocessing', the architecture tallies with our definition of AMP in that the processors are instruction-set compatible and all user code can run on any processor (probably true of system code as well, but that's not required).

big.LITTLE may be used as a highly-scalable uniprocessor by migrating the entire workload to the most appropriate core for the conditions, or as independent processors with different performance characteristics (requiring an AMP-aware scheduler to place user jobs on the most appropriate core).

References:

• Web page
• White paper

--Streapadair (talk) 17:26, 28 November 2012 (UTC)

...less expensive options on systems...

part 1

Recently added to the first paragraph is this text: “It has also been used to provide less expensive options on systems where SMP was available.” There is no citation for this statement, and it is not obviously correct. Can anyone provide a citation or argument for its correctness? If not I propose to delete it. John Sauter (talk) 19:40, 16 March 2013 (UTC)

I've added {{cn}} to the claim to reflect the lack of, and requirement for, a citation. Guy Harris (talk) 23:13, 16 March 2013 (UTC)

There were already citations for the IBM Attached Processor systems elsewhere in the article, but I added an additional citation at the beginning. Shmuel (Seymour J.) Metz Username:Chatul (talk) 16:53, 20 March 2013 (UTC)

An attached processor is not the same as asymmetric multiprocessing. The reference contains no mention of price, and it states that the operating system for both the multiprocessor and attached processor configurations is OS/VS2. As best I can tell, there is no software differences between the multiprocessor and attached processor configurations, and the only hardware difference (from the customer's point of view) is that I/O devices cannot be attached to the attached processor. Thus, the reference does not support the statement, and I continue to believe it should be deleted unless it can be supported. John Sauter (talk) 13:15, 24 March 2013 (UTC)

How is a S/370 with an attached processor not an asymettric multiprocessor system? It has two processors ans the OS cannot treat them symmetrically.

As to price, when the vendor offers a less capable option and a more capable option, it's a reasonable assumption that there is a difference in price; otherwise the customer would never select the less capable option.

OTOH, if I can find a sales manual I will add a note as to the size of the price difference. Shmuel (Seymour J.) Metz Username:Chatul (talk) 18:57, 29 March 2013 (UTC)

The operating system can certainly treat an attached processor the same as a second full processor which happens to have no I/O devices. Since there is no software difference between the full multiprocessor and the attached processor, you cannot call just one of them asymmetric. As to price, you cannot assume anything about prices because there may be other reasons than price to choose the attached processor over the full multiprocessor. The attached processor might require less floor space, less power, or less air conditioning, for example. John Sauter (talk) 14:08, 2 April 2013 (UTC)

"The operating system can certainly treat an attached processor the same as a second full processor which happens to have no I/O devices." That means that the software treats them differently; it doesn't run the I/O code on the second processor. It may be "full" in the sense of being able to run all non-OS code, and may even be "full" in the sense of being able to run OS code that doesn't directly issue I/O operations (e.g. it could do all the work of opening a file except for actually starting the I/O operations involved with looking up the file), but it's not "full" in the sense of being able to do everything the "primary" processor can. Such a system is asymmetric at the hardware and OS level.

A multiprocessor system in which any processor could, at the hardware level, issue an I/O operation, but in which the OS is only allowed to run on one of those processors, so that a program running on another of the processors must, when it makes an OS call, send some sort of message to the first processor and wait for the "OS processor" to pick up the message, perform the OS call, and then reply to the message, is symmetric at the hardware level but asymmetric at the OS level. If the OS were later modified to allow OS code to run on any of the processors, whether with a giant lock or some form of finer-grained locking, the system would them be symmetric at the OS level as well. Guy Harris (talk) 21:38, 5 April 2013 (UTC)

I'm still looking for a full price list, but comparing Attached processor complex Technical press release to 3033 Multiprocessor Technical press release, I see that an 8 MiB 3033 MP costs more than a 12 MiB 3033 AP. Shmuel (Seymour J.) Metz Username:Chatul (talk) 21:44, 3 April 2013 (UTC)

The references to the IBM 3033 support the claim that the attached processor is less expensive than a full multiprocessor. What remains unsupported is the claim that a multiprocessor is any more or less an asymmetric multiprocessor than the attached processor. In the references you cite, the only difference between the configurations are that the attached processor has a slightly different clock speed and no channels. There is no hint of any software differences. John Sauter (talk) 19:12, 4 April 2013 (UTC)

Most of the systems listed in the article have no software differences among the central processors. The B5000 has a software distinction, and perhaps the PDP-10 does, but Multics, the CDC 6x00 operating systems, the IBM operating systems and UNIVAC EXEC 8 treat the central processors identically. The only software asymmetry in any of them is that on the CDC 6000 and 7000 line the operating system runs on the 12-bit peripheral processors and only applications run on the 60-bit central processors.

Now, I do know of some other systems where there is a software difference among processors, but they are not listed in the article. These include

• Bendix G-21 (not sure)
• IBM Attached Support Processor (ASP)
• IBM Direct Coupled System (DCS)
• IBM Job Entry Subsystem 3 (JES3)
• IBM 9020 Shmuel (Seymour J.) Metz Username:Chatul (talk) 19:31, 5 April 2013 (UTC)

"Most of the systems listed in the article have no software differences among the central processors." If there's truly no software difference, in that OS code can run on any processor, even if there's a giant lock around that code so that if it's running on one processor and another processor tries to run it,, the other processor has to spin waiting for the first processor to finish, then it's not asymmetrical, it's symmetrical with a giant lock. Guy Harris (talk) 21:30, 5 April 2013 (UTC)

part 2

You misunderstand the meaning of asymmetric multiprocessing. When multiprocessing was young, operating systems were minimally modified to support the second processor. That was called asymmetric multiprocessing because the operating system developers were looking forward to symmetric multiprocessing, which required many years of development. As operating systems did a better job of supporting multiple processors, we can look back and see the progress from asymmetric multiprocessing to today's symmetric multiprocessing. Removal of the giant locks was a big part of that progression.

To return to the main point of this topic, the fact that there is no software-detectable difference between a multiprocessor and an attached processor means that either both are asymmetric or both are symmetric, depending on the capabilities of the software. You cannot call one of them asymmetric and the other symmetric, because there is no software difference between them. John Sauter (talk) 07:44, 6 April 2013 (UTC)

No, I understand the meanings of asymmetric and symmetric multiprocessing completely. The meaning of asymmetric multiprocessing is "some processors do different things from other processors (with the exception of system startup and shutdown, where the might be a "boot processor" that does the initial startup operations before starting up the others and the final shutdown operations after the others have shut down)"; otherwise, there's no asymmetry, and the system being described cannot validly be described as "asymmetric".

What does “Asymmetric Multiprocessing” mean

part 1

A system wherein only one particular designated processor (in the sense of "one particular collection of transistors") runs OS code, for example, is asymmetric; a system wherein any processor can run OS code is symmetric, regardless of whether there's a giant lock that allows only one processor to run OS code at any given instant or more fine-grained locks allowing more than one processor to run OS code at the same time.

Whether a system is asymmetric or symmetric is an issue of the entire system - both the hardware running on it and the software running on it:

• A system in which, for example, the I/O devices or channels are connected to one particular processor, so that the other processors cannot issue I/O instructions, would inherently be asymmetric, as would a system in which, for example, the "trap to privileged mode" instruction is wired up on one processor to cause a trap of some sort to privileged-mode code and, on the other processors, is wired up to halt that processor and deliver a "another processor executed a trap to privileged mode" trap to the first processor, would also inherently be asymmetric, as, in both of those cases, there are hardware differences between the processors.

• A system in which all processors are capable, at the hardware level, of running privileged-mode code and starting I/O operations, but in which the OS that happens to be running on that system only runs the privileged-mode code on one particular processor, is also asymmetric.

The difference between the first type of system and the second type of system is that the first type of system can't be made symmetric by changing the OS, but the second type of system can. Guy Harris (talk) 18:14, 6 April 2013 (UTC)

We disagree about the definition of the term “asymmetric multiprocessing”. I claim it is an obsolete computer science and computer marketing term, and I have citations (in the main article) to demonstrate my point. Your definition is a reasonable one, but do you have citations to justify it? 14:08, 7 April 2013 (UTC) — Preceding unsigned comment added by John Sauter (talk • contribs)

part 2

It may well be "obsolete" in that people aren't building, for example, master/slave MP systems, but that's "obsolete" in the sense that the term "core memory" is obsolete; it's not as if it shouldn't be used to describe systems in the past. I'm not sure what the point of saying it's an "obsolete term" is.

As for references, let's look at some of the references in the article.

Chapter 1, HISTORICAL PERSPECTIVES, of Introduction to Multiprocessing talks about the IBM Stretch being an "asymmetric multiprocessor in which each processor had a separate and distinct function", with one processor "used for binary arithmetic" and another being "used for character operations". I suspect they're referring to the IBM 7950 Harvest, with the "stream coprocessor" being what was "used for character operations". That does, indeed, match what, these days, is generally being referred to as a system with coprocessors. In the same paragraph, they talk about the IBM Direct Coupled System, where the 7044 acted as "a communications processor" according to that document and a machine "performing I/O operations" according to the Wikipedia article for the 7090; in either case, it's a system with a front end processor (which could control I/O devices other than communications devices).

Chapter 2, DEFINITIONS AND COMPARISONS, speaks of a "multicomputer" as "a system that has two or more computers sharing data at the data-set level", and a "multiprocessor" as having multiple computers with some amount of shared memory (tightly coupled if most of the communication is through shared memory, loosely coupled if most communication is over a shared bus), at least some shared I/O devices, and "one operating system". They speak of "asymmetric" multiprocessors as multiprocessors not having "equal performance and functionality"; given that an earlier example of that was a Stretch with a coprocessor, the "one operating system" presumably needn't run on all the processors - the coprocessors could presumably be controlled by the OS on the "main" processor, just as long as the system doesn't look as if the coprocessors are running their own full-blown OSes.

Chapter 5, MULTIPROCESSING SOFTWARE, says:

...Multiple processors may be arranged hierarchically (dissimilar) or symmetrically (identical) to produce the preferred result.

Hierarchical Systems

A hierarchical system reduces complexity in system design by producing predefined dependencies. An example of a hierarchical system is a master/slave arrangement in which one of the processors is considered superior to the others. In a typical master/slave organization, the master may be responsible for distributing the work load to the slave processors. For example, the system may be programmed so that only the master can respond to interrupts, but the resulting work can be handled by any one of the slave processors.

...

Symmetric Systems

Symmetric systems treat all processors equally, execute common operating system code, and share all devices.

That chapter speaks of both master/slave and symmetric PDP-10 systems; they say that, in the PDP-10 systems, "the slave has no I/O devices (except a console terminal)", so that sounds like a system where the asymmetry is in hardware, not just in software, but they also say "A symmetric multiprocessor requires only new software; the hardware is essentially unchanged", which seems to be saying, if taken literally, that no multiprocessor hardware systems exist in which only one processor has peripherals attached to it. That matches the earlier definition, so presumably "the slave has no I/O devices" doesn't mean "the slave has no hardware connection to any I/O devices"; it must mean "the slave does not touch the I/O devices to which it has access, it lets the master handle that". A DEC paper on TOPS-10 SMP doesn't indicate whether the KA-10 multiprocessor systems were "multcomputers" or "multiprocessors" in the sense used in the previous DEC reference; they say that the SMP version of TOPS-10 didn't have to run on the KA-10. They speak of dual-ported disks; I don't see any indication of any other mechanism used to allow multiple processors to access the same peripherals.

RSX-11M multiprocessing (PDP-11) defines "symmetrical system" as "synonymous with multiprocessor system", with "multiprocessor system" described as "generally" giving "each unit" "common access to at least a portion of the I/O devices", and seems to speak of a system where that's not the case as a "multicomputer system".

Appendix G of IBM (January 1976). IBM System/370 Model 168 Functional Characteristics (PDF). Fifth Edition. GA22·7010-4. {{cite book}}: Unknown parameter |separator= ignored (help) says, of the IBM 3062 Attached Processing Unit, that "the APU has no channels attached", so a 370 Model 168 with an APU is an asymmetric system where the asymmetry is in hardware. Appendix E seems to indicate that, in the MP configuration, each CPU has channels attached to it, and that each CPU has some sort of control over the channels attached to the other CPU if that CPU is stopped, so maybe you could speak of a asymmetry in that not all channels are accessible to all CPUs. However, it also speaks of a "two-channel switch feature", which sounds as if it allows a peripheral to be controlled from two different channels (whether attached to the same CPU, presumably for redundancy, or attached to different CPUs), so that might allow either CPU to control all peripherals, rendering that system symmetric.

Operational Characteristics of the Processors for the Burroughs B5000 seems to indicate that only Processor Module A has an I/O Exchange, so that's another asymmetric-in-hardware system.

So, for the definitions used in the two DEC documents, systems such as the Burroughs B5000 and the IBM System/370 Model 168 with a 3062 Attached Processing Unit aren't "asymmetric multiprocessors", but not because they're not asymmetric (there's most definitely asymmetry between the processors!) - it's because they're not multiprocessors at all, they're "multicomputers", because not all processors have access to the I/O devices. I'm not sure how they'd categorize the MP configuration of the Model 168, given that not all processors have equal access to all peripherals, but maybe it'd be a "symmetric multicomputer", in that the processors don't have "[unequal] performance and functionality" - it's not as if one of them has more performance or functionality, at least not if you've attached as many peripherals to the channels on the second processor as you've attached to the channels on the first processor.

I.e., if you go by the definitions in the two aforementioned DEC documents, we should remove the B5000 from this page, as it's not a multiprocessor, just a multicomputer. The APU configuration of the 370/168 should be removed for the same reason; I'm not sure what should be done with the MP configuration of the Model 168.

On the other hand, the VAX Product Sales Guide shows the VAX-11/782 in a fashion that indicates that the peripherals are connected to one particular processor, referring to the second processor as an "attached processor" and saying that "All peripherals are attached to the primary processor ONLY; they are not supported by the attached processor". However, the fact that it would be a "multicomputer" by the definitions in the other DEC documents nonwithstanding, they refer to it as an "asymmetric multiprocessing system"! Perhaps a "multiprocessing system" isn't necessarily a "multiprocessor", or perhaps they just didn't get the memo. :-) In any case, if the 11/782 is an "asymmetric multiprocessor", then so are the B5000 and the APU configuration of the 370/168.

So, if we only go by DEC's documents, the question is whether an "asymmetric multiprocessing system" is an "asymmetric multiprocessor". If so, then the definitions of "multiprocessor" in the first two DEC references I cite should be ignored, and systems in which all I/O devices are attached to one particular processor are multiprocessors, and obviously asymmetric multiprocessors at that, including the B5000, the APU configuration of the 370/168, and the VAX-11/782. If not, then neither the B5000, the APU configuration of the 370/168, and the VAX-11/782 aren't multiprocessors, but multicomputers, and shouldn't be described on a page about "asymmetric multiprocessing", unless you can do "asymmetric multiprocessing" on a system that's only a multicomputer, not a multiprocessor.

In either case, the MP configuration of the 370/168 appears to be, at the hardware level, a symmetric multiprocessor if all devices are attached with a two-channel switch, and, depending on whether "symmetric" means "all machines can get at all peripherals" or "no one machine is given all the peripherals", symmetric or not.

(In addition, the "SYSTEM PERFORMANCE DEGRADATION" section of Chapter 5 of the first DEC reference seems to speak of a giant lock ("Such an instruction is used to program a mutual exclusion code surrounding the kernel."), so they seem not to consider a giant lock to make a system asymmetric. Given that, and given that, on the Multics machines, all peripherals were available to all devices, and no processor was designated as the processor to do all the I/O, Multics was not what would be called an asymmetric multiprocessor, and should be removed from this page.) Guy Harris (talk) 20:59, 7 April 2013 (UTC)

part 3

You are mixing definitions from different manufacturers, and so you are getting some nonsense results, as you seem to realize. DEC defined a multiprocessor as having some shared peripherals, because that is what the PDP-11 product line was selling. Other DEC product lines, and other manufacturers, were selling multiprocessors in which only the master processor could do I/O, as you note. The industry generally followed IBM, which defined a multiprocessor as a computer system with more than one processor that shared main memory, and a multisystem as a computer system with more than one processor that did not share main memory, but communicated some other way, such as through a channel-to-channel adapter (CTCA).

If your definition of a symmetric multiprocessor only requires that the processors have identical hardware, both can do I/O, and both run the operating system, then only the B5500 would be asymmetrical. Here's an example where that definition gives a silly result: take a PDP-6 computer system, add a KA10 processor (thus turning it into a PDP-10), put almost all of the I/O devices on the KA10, run the operating system on the KA10, and add a system call to the operating system which allows a user program to start the PDP-6 CPU at a particular place in its address space. By your definition, that would be a symmetric multiprocessor, since the CPUs are functionally identical, both address I/O devices, and they share main memory.

Even the IBM attached processors meet your definition, since they have an I/O device: their console keyboard/printer.

If the term is to have any meaning beyond the B5500, as it did, a better definition is required. Historically, it was defined as described in the article. Now that all multiprocessors are SMP, the term is no longer used, and so I called it “obsolete”. As you said, the term is obsolete only in the sense that such computers are no longer being sold, just as the term “core memory” is obsolete.

I think it would be reasonable to say that the term has changed with time. When the IBM 7030 (Stretch) was built, there were no multiprocessors. As you noted, we now use the term coprocessor to refer to the Stretch organization of processors with different functions, but that was called asymmetric at the time. The Burroughs B5500 redefined asymmetric multiprocessing. The DECsystem-1055 product was preceded by two prototypes at universities: one at MIT and the other at Stanford. The one at Stanford was the upgraded PDP-6 I mentioned above, in which only a small part of the operating system ran on the second processor. These were called asymmetric because they were very similar to the B5500, but built out of identical processors with software to do what in the B5500 was done in hardware: prevent the second processor from running any but a tiny part of the operating system, and not doing any I/O on the second processor, even though it had an I/O bus. (The I/O device on the second CPU at Stanford was handled by letting the user program address it directly.)

As time passed, the operating system made better and better use of the second processor, and eventually the term asymmetric was dropped. However, even the term symmetric multiprocessing is a moving target. Multics considered itself a symmetric multiprocessing system, but it would not be considered such today because it did not allow an unprivileged user program access to more than one processor at a time. John Sauter (talk) 13:38, 8 April 2013 (UTC)

"You are mixing definitions from different manufacturers". I'm also mixing two definitions from the same manufacturer - DEC. They spoke in the two documents from the PDP-11 SMP era of systems that didn't allow all processors equal access to I/O devices as being "multicomputers" rather than "multiprocessors", but they spoke in the VAX document of the VAX-11/782, in which the I/O devices were all attached to the "primary" processor, as an "asymmetric multiprocessor system", rather than as a "multicomputer".

"If your definition of a symmetric multiprocessor only requires that the processors have identical hardware, both can do I/O, and both run the operating system, then only the B5500 would be asymmetrical. ... Even the IBM attached processors meet your definition, since they have an I/O device: their console keyboard/printer." That's not my definition. I view symmetry as a characteristic of the combination of hardware and software. A system that doesn't allow all processors to access I/O devices is asymmetric at the hardware level and thus inherently asymmetric at the software level. A system that does allow all processors to access I/O devices (and in which the processors are all identical) is symmetric at the hardware level; however, when running a "master/slave" operating system, it's asymmetric at the software level. Replace the OS with one that's not master/slave, even with a giant lock, and it's now symmetric at the software level.

"Multics considered itself a symmetric multiprocessing system, but it would not be considered such today because it did not allow an unprivileged user program access to more than one processor at a time." I see no asymmetry in such a system; all processors are treated equally. Do you have any citations for the ability for a user session to have more than one thread of control ever being considered a sine qua non of being a symmetric multiprocessing system? Guy Harris (talk) 19:11, 8 April 2013 (UTC)

The various product lines at DEC acted like different manufacturers. There are both strengths and weaknesses in that kind of organization.

Except for the B5500, multiprocessors were generally built out of the same CPUs as the corresponding uniprocessor. On the DECsystem-1055, there was a switch which caused the UUO instructions to trap to either location 40 or location 140. On a multiprocessor you set the switch differently for the two processors, but the switch was present even if you had only one CPU. I believe (but I am not certain) that the second processor in the VAX-11/782 was the same as the first processor—the restriction on I/O devices was based on software limitations, and perhaps some I/O bits were missing. For the IBM System/370 models 158 and 168, I wouldn't be surprised if the attached CPU was identical to the second CPU in the multiprocessor configuration. IBM was known for pricing their products based on what the market will bear, rather than as a function of manufacturing cost. Notice that the attached processor configuration can be upgraded to a full multiprocessor in the field.

Thus, if your definition of “Asymmetric Multiprocessing” requires asymmetry in either the hardware or software, the widespread use of identical CPUs means you are essentially testing just the software, as I am.

However, how do you classify a smartphone which has two CPUs: one runs fast and uses lots of power, and the other runs slow and uses little power? The CPUs are not identical at the hardware level; would you call this an asymmetric multiprocessor even though it runs Linux, which regards itself as SMP? The two CPUs have the same instruction set, so they appear identical to the software.

On the topic of Multics, I consider SMP to be a term whose precise definition has evolved over time. SMP really means that the operating system does a much better job than the old ASMP systems of making good use of all CPUs. Those improvements have been made over a period of almost 50 years, so an old system, even if considered SMP at the time, would not use the processors as efficiently as a modern system, and so would not meet today's definition of SMP. No, I don't have a citation for that. John Sauter (talk) 12:48, 9 April 2013 (UTC)

part 4

"The various product lines at DEC acted like different manufacturers." OK, so I shall interpret your statement "You are mixing definitions from different manufacturers" as meaning "you are mixing definitions from different organizations", to make it clearer that you did not only mean "from different corporations". In either case, this demonstrates that citing references from the article can't resolve the question of, for example, whether a system such as the B5000, APU configuration of the 370/168, or VAX-11/782 is an "asymmetric multiprocessor", as some references would indicate that it's not a multiprocessor at all, just a multicomputer (the PDP-11/74-era DEC documents) and others would suggest it is, indeed, an asymmetric multiprocessor (the VAX marketing guide).

When you say "identical CPUs", what do you mean by "identical"? Do you mean "capable of running the same unprivileged-mode code with the same performance", or do you mean "capable of running the same unprivileged-mode and privileged-mode code with the same performance, but not necessarily having equal access to all of the peripherals" (so that, for example, all CPUs might be capable of performing I/O instructions, but only some of the CPUs might be able to successfully execute an I/O instruction to control some or most peripherals), or do you mean "capable of running the same unprivileged-mode and privileged-mode code with the same performance, and having equal access to all of the peripherals"?

I'd reserve the term "multiprocessor" for systems where all processors are, at minimum, capable of running the same unprivileged-mode code with the same performance, so my first-generation iPhone isn't a multiprocessor - the two ARMs aren't capable of running the code with the same performance (and they might not even run the same version of the ARM instruction set). I could see people arguing that systems where not all processors can, at the hardware level, run privileged-mode code (as the B5000 documentation seems to indicate is the case for the two-processor version - "However, when the Interrupt Register signals that a special condition has arisen within the system, Processor A automatically switches to the Control State ... While in the Control State, certain operations can be performed, which would be ignored by the processor if they were encountered in the normal state", emphasis mine, in the first paragraph on the second column of the first page of Section 2 - Organization of the B5000 operational characteristics document), or where not all processors can, at the hardware level get at peripherals other than (perhaps) a system console (as the references for the APU 370/168 and the VAX-11/782 seem to indicate is the case - "the APU has no channels attached and has no channel activity" in the second paragraph in the second column of the first page of Appendix G of the 370/168 Functional Characteristics document, and "All peripherals are connected to the primary processor ONLY; they are not supported by the attached processor", and the accompanying diagram, on page 1-23 of the VAX sales guide document) as being multiprocessors or as being "multicomputers" or "attached processor systems" (the VAX sales guide refers to the 11/782 as having an "attached processor" and as being an "asymmetric multiprocessor", but IBM considers the APU version of the 370/168 as an "attached processor" system, distinct from the MP version.

The MP version of the 370/168 might, or might not, give all processors access to all peripherals, as the documentation appears to indicate that the two processors have separate channels (rather than two paths to the same set of channels), with a processor being able to take over the other processor's channels only if the other processor is stopped (presumably so that all peripherals are accessible even if one processor fails, allowing the system to gracefully handle the failure of a processor), but it also speaks of dual-ported disks, which might be accessible by either of the processors if the two channels to which the disk controller is attached are channels on different processors rather than separate channels on the same processor. I don't know whether any tape drives or unit-record devices supported dual-channel attachment. If such a system doesn't grant to all CPUs access to all peripherals on an equal basis, I could see some not considering it to be a multiprocessor (although IBM did consider that system a multiprocessor, so either it did grant to all CPUs access to all peripherals on an equal basis, or IBM doesn't consider that a sine qua non for a multiprocessor system).

Once we have a definition of "multiprocessor", I'd say:

• any system where not all processors have the hardware ability to execute privileged-mode code, if considered a multiprocessor at all, is an asymmetric multiprocessor, as the processors are clearly not identical, i.e. there's no symmetry between the processors;

• any system where all the processors have the hardware ability to execute privileged-mode code, but don't have equal access at the hardware level to all peripherals, if considered a multiprocessor at all, is an asymmetric multiprocessor, as the processors don't have identical abilities to perform I/O, i.e. there's no symmetry between the processors (although the more access processors have to various peripherals, the less strong the asymmetry, i.e. if the MP 370/168 is considered asymmetric, e.g. because under normal circumstances only one of the processors can talk to the unit record equipment, or because some disks are available only to the first processor and others are available only to the second processor, that's less strongly asymmetric than the APU 370/168 or the VAX-11/782);

• any system where all the processors have the hardware ability to execute privileged-mode code, and have equal access at the hardware level to all peripherals, but the operating system only allows some processors to perform I/O operations, is an asymmetric multiprocessor, as, while the processors are identical at the hardware level, and have the same access to all peripherals, the OS doesn't treat them equivalently, i.e. the OS doesn't treat them in a symmetrical manner;

• any system where all the processors have the hardware ability to execute privileged-mode code, and have equal access at the hardware level to all peripherals, and where the operating system allows all processors to perform I/O operations, is a symmetrical multiprocessor, as there's symmetry at the hardware and OS level between the processors.

So I could see merit to both sides of the dispute over the two dual-processor flavors of the 370/168 - I could see the APU flavor not considered a multiprocessor at all, and could also see it considered a multiprocessor (IBM didn't call it a multiprocessor, and distinguished it from the MP configuration, which they did say supported "multiprocessing", and the 11/74-vintage DEC documents would consider it a "multicomputer", but it's like the 11/782, which the VAX sales guide called an "asymmetric multiprocessor"), and could even see some considering the MP version not to be a symmetric multiprocessor or not a multiprocessor at all if not all CPUs have equal access to all peripherals (but IBM definitely referred to it as a multiprocessor).

part 5

You appear to recognize that there are degrees of asymmetry: a 370/168 MP in which all but one of the peripherals are accessible to both CPUs is “less asymmetric” than one where all of the peripherals are attached to one of the CPUs. Do you also recognize that there can be degrees of asymmetry due to software? John Sauter (talk) 20:10, 9 April 2013 (UTC)

Yes. For example, on a machine where all processors are capable of running privileged code, and where the I/O devices are accessible to all processors, you could have an OS where all but one processor, when making a call to privileged code, must block the thread of control making the call and request that the one processor allowed to perform privileged-mode operations perform the privileged-code function, and you can have an OS where all processors can run privileged code but all but one processor, when it needs to perform an I/O operation, must block the thread of control starting the I/O function and request that the one processor allowed to perform I/O operations start the operation. Guy Harris (talk) 01:30, 10 April 2013 (UTC)

Then perhaps you would agree that there is a continuum between fully asymmetric and fully symmetric multiprocessing, with the B5500 at one extreme, a modern Linux system at the other, and the various historical multiprocessors in the article at various places in that continuum? John Sauter (talk) 02:15, 10 April 2013 (UTC)

part 6

No, I would not.

I would, however, agree that:

• there are systems that are symmetric, wherein all processors are, at the hardware level, capable of running the same user-mode and privileged code and accessing all the machine's peripherals, and where the OS uses them equivalently, that being what "symmetric" means, and all other systems are asymmetric in some sense (although, as there are systems where there aren't some "distinguished" processors, but in which processors don't have equal access to all of the system's resources, such as a NUMA system or, as the 370/168 MP might have been, "NUPA" systems, in which there's no distinguished "I/O CPU" that has all the peripherals attached to it, but in which each processor has a similar set of peripherals attached to it, but if processor X wants to perform an I/O operation on peripheral A, it has to ask processor Y to do it, so perhaps we need another dimension in the multi-dimensional space used to categories MP systems, separate from the degree of asymmetry);

• all other systems are asymmetric, and there's a scale of asymmetry, so that, for example, a system in which only one processor can execute privileged code is more asymmetric than a system in which all processors can execute privileged code but only one processor has the peripherals connected to it, which is more asymmetric than a system in which all processors can execute privileged code and have peripherals attached to them, but one processor has all the peripherals incapable of dual-porting attached to them;

• there is more than one "figure of merit" for a multiprocessor system, and the degree of (or lack of) asymmetry is only one of them, with others being how fine-grained the locking is (so that a system with a giant lock is less finely-grained than a system that protects various large subsystems with locks, which is less finely-grained than one that protects individual data structures with their own locks) and another perhaps being how uniform the access to system resources is (if "asymmetric" is distinguished from "non-uniform access", so that a NUMA system provides less uniform access than a "UMA" system, and a system in which all processors have the same amount of secondary storage and the same number of communication lines attached to them, so that "asymmetric" might be a misleading term, but in which only the processor or small processor group to which they're attached can directly access them, so that "symmetric" would also arguably not be accurate, provides less uniform access than a system in which any processor can start I/O on any peripheral);

• whether the system supports multiple threads of control within a single process does affect how much use certain applications and certain workloads can make of multiple processors (which is more relevant on a personal computer than on a time-shared computer and perhaps more relevant on a time-shared computer than on a server, although having multiple threads in a shared address space might be better than having multiple processes in separate address spaces even on a server), although supporting multiple threads of control within a single process can also be useful even on a uniprocessor system, so I don't consider it to be a figure of merit for multiprocessor systems in exactly the same sense as the degree of asymmetry or the fine-grainedness of the locking is.

So I think a system is either symmetric or it isn't, so applying the term "fully" to "symmetric" makes no sense, and, whilst there's a continuum between a fully asynchronous system and a symmetric system, stuff in the middle is asymmetric. I also don't think asymmetry is the only figure of merit for an MP system, so, whilst there are systems that can make better use of multiple processors than others, it's not as if a system that makes better use of multiple processors is inherently "more symmetric" than one that doesn't make as good use of multiple processors; it might "have finer-grained locking" even though both systems are symmetric, or it might offer threading within a process where the other doesn't, even though both systems are symmetric.

I.e., I do not believe that the term "symmetric" or "asymmetric", when applied to "multiprocessing" or "multiprocessor", can validly be used in a fashion so as to refer to anything other than the symmetry between processors, and I believe that it is logically impossible to construct a rational argument in favor of using it in a fashion that refers to anything other than the symmetry between processors, so attempts to convince me that a system in which all processors are equal, but in which there is a giant lock around the privileged-mode code, or in which a process can have only one thread of control, are, as far as I am concerned, a demonstration that the person making that attempt either does not understand what the words "symmetric" or "asymmetric" mean, or are, Humpty-Dumpty style, using the words for their own purposes, quite unrelated to the way the words are defined in the dictionary or used by most people. Guy Harris (talk) 18:59, 10 April 2013 (UTC)

You make a good argument for what the term “asymmetric multiprocessing” ought to mean, based on the meaning of the underlying words, but this is unavailing. If there is to be an article on asymmetric multiprocessing it must describe what the term meant, even though there are good arguments that it should have meant something else. The term is no longer used, so the article can only describe its historical usage. As the references in the article make clear, it was used in computer marketing from about 1960 to about 1985 to refer to such multiprocessors as the B5500, the DECsystem-1055 and the VAX-11/782. Later multiprocessors were called symmetric, and today the term SMP is synonymous with multiprocessing.

it is not unusual for marketing people to use words for their own purposes, quite unrelated to the way words are defined in the dictionary. However, this term wasn't entirely the creation of marketing. The engineers of the time also called their hacks to make use of the second processor asymmetric multiprocessing because they were looking forward to being able to provide much better support for multiprocessors someday, and that would be symmetric multiprocessing, where processors are not limited in their capabilities due to software limitations. John Sauter (talk) 12:27, 11 April 2013 (UTC)

part 7

"As the references in the article make clear, it was used in computer marketing from about 1960 to about 1985 to refer to such multiprocessors as the B5500, the DECsystem-1055 and the VAX-11/782." All of those systems do, in fact, have a lack of symmetry between the processors.

"Later multiprocessors were called symmetric" - because they did have symmetry between the processors.

"The engineers of the time also called their hacks to make use of the second processor asymmetric multiprocessing because they were looking forward to being able to provide much better support for multiprocessors someday" - they added a qualifier to "multiprocessing" because they were looking forward to being able to provide much better support for multiprocessors someday, and they chose the qualifier "asymmetric" because the systems were not symmetric and the "much better support" they had in mind was making them symmetric.

"and that would be symmetric multiprocessing, where processors are not limited in their capabilities due to software limitations." Well, software limitations and hardware limitations where only some processors have the physical ability to run privileged code or to control particular peripherals.

A giant lock does not limit the capabilities particular processors have; it limits, instead, the extent to which more than one processor can run in certain sections of code. If a particular line of multiprocessors were to start out as master/slave, allow all processors to run privileged code and perform I/O operations in a later OS release (and perhaps with later versions of the hardware, if those limitations were in part or in whole due to hardware limitations) with a giant lock, and still later were to make the locking more fine-grained, symmetry would have been achieved by the second step; the subsequent improvement is that the system achieved fine-grained locking, not symmetry.

The lack of multiple threads of control within a single process does not limit the capabilities particular processors have; it limits, instead, the extent to which the code within a process can be run in parallel, with more than one processor participating. If a particular line of processors were to start out as master/slave and not have multiple threads of control within a single process, allow all processors to run privileged code and perform I/O operations in a later OS release (and perhaps with later versions of the hardware, if those limitations were in part or in whole due to hardware limitations) and still not allow multiple threads of control within a single process, and still later were to add support for multiple threads of control within a single process, symmetry would have been achieved by the second step; the subsequent improvement is that the system achieved threading, not symmetry.

And, on the other side, a system in which all processors can execute privileged code, but not all processors can perform I/O operations on most peripherals (for hardware or software reasons), could lock what privileged code is run on all processors with fine-grained locks, and could support multiple schedulable threads within a single process. Such a system is asymmetric, not symmetric. It might not have been deemed worthwhile, at the time asymmetric systems were being built, to provide those capabilities in those systems, but they are still technically possible to provide.

I.e., symmetry, fine-grained locking, and threading within processes, all of which allow a system to make more full use of multiple processors, are orthogonal capabilities. The lack of symmetry makes a system asymmetric; neither the lack of fine-grained locking nor the lack of threading within processes on a system with symmetry between processors makes a system asymmetric.

I have seen no indication that the term "asymmetric" was used to describe a system for any reason other than the lack of symmetry between the processors. What you described was people using it in anticipation of systems that provided symmetry between processors, regardless of how fine-grained the locking was in those systems or how many threads of control were supported within a process. Guy Harris (talk) 18:33, 11 April 2013 (UTC)

Your arguments are cogent and well thought out. I think it is time to start updating the article. Much of what you have written could be placed in the article to describe asymmetric multiprocessing and how it relates to other multiprocessing concepts. If you will do the initial edit I will be happy to help. John Sauter (talk) 00:59, 12 April 2013 (UTC)

Multics as "asymmetric"

It sounds as if you have a definition of "SMP" that has nothing to do with symmetry, but have no citations for that. As such, I consider it to be your personal definition, rather than a standard definition, and, as it uses the term "symmetric" but doesn't consider a system that's completely symmetric, at the hardware and software level, with regards to the processors, as being symmetric, merely because it does not support multiple threads of control within a single process, I consider it an inaccurate, confusing and misleading definition. There are several ways to improve the use of CPUs by an MP system; removing hardware and software asymmetry is only one of them - making the locking finer-grained is one (and that's "finer-grained", so it's not as if you have a giant lock and then you have "fine-grained locking"; you can go past a single giant lock - earlier versions of OS X didn't have a single giant lock, but weren't generally all that fine-grained in their locking - and it improved over time), as would be adding support for kernel-level threading within a single process to a system that didn't have it.

So I see no valid reason to consider Multics ASMP, and will remove it from this page. Guy Harris (talk) 16:48, 9 April 2013 (UTC)

Clarification of two-channel switch on IBM S/360 et al

The two channel switch on IBM S/360 & S/370 control units allowed attaching two channels, without restriction as to whether those channels were on the same processors, distinct processors in the same multiprocessor or distinct processor complexes. In particular, a shared DASD configuration had systems with distinct operating systems accessing the same DASD volumes, using the RESERVE and RELEASE commands to preserve atomicity as needed. Newer controllers greatly expanded the number of channel atachments. Shmuel (Seymour J.) Metz Username:Chatul (talk) 21:25, 8 April 2013 (UTC)

Yes, that's why I said "(whether attached to the same CPU, presumably for redundancy, or attached to different CPUs)". In the MP version of the 370/168, were there configurations in which, if neither processor was in the stopped state, some peripherals could only be accessed by one of the processors? If so, did that apply to any peripherals other than the console (I'm inferring from Appendix E that the two CPUs have two separate consoles)? Guy Harris (talk) 02:48, 9 April 2013 (UTC)

It was common to have peripherals that could be accessed by only one CPU. The operating system was able to “shoulder tap” the other CPU, when necessary, to start an I/O operation. For OS/360 release 21, telecommunications devices were only permitted on one CPU, though that restriction may have been lifted by the time of the System/370 model 168, which ran OS/VS2. See the I/O Supervisor PLM, referenced in the main article, particularly page 272. John Sauter (talk) 12:18, 9 April 2013 (UTC)

The IBM 2701, 2702 and 2703 could only attach to one channel, and hence to one CPU. The later IBM 3705 Communications Controller could attach to multiple channels, and hence multiple CPU's. Shmuel (Seymour J.) Metz Username:Chatul (talk) 20:43, 11 April 2013 (UTC)

Yes, as noted by John, a 270x could only attach to a single channel. It could be switched via, e.g., a 2914, but that required varying it offline on one side, stopping both processors and varying it online on the other side. I believe that with the 3814 you didn't need to stop the processors, but you still needed the VARY commands. And, yes, each processor had its own console. Shmuel (Seymour J.) Metz Username:Chatul (talk) 20:43, 11 April 2013 (UTC)

So, when it came to "Tele-Processing", a dual-processor system with a 270x wasn't symmetric; even if all disks had a two-channel switch and were accessible to all processors (in a two-processor system), one processor could directly talk to the communications controller and the other processor would have to ask the processor to which the controller is attached to do so. If the OS only allowed telecommunications devices on one CPU, even a system with a 3705 would be asymmetric.

What about unit record equipment and mag tapes; could any of them be attached to more than one channel? Guy Harris (talk) 23:20, 11 April 2013 (UTC)

I am not familiar with the 3814, but I do know that the vary offline command did not require stopping a processor. It was an operating system command which caused the operating system to stop using the device. If the command was successful the device could be moved to the other channel and then varied online.

Unit record equipment was interfaced through the IBM 2821, which had a two channel switch option. I am not sure about mag tapes since there were several controllers, but I think they also had two-channel switches. John Sauter (talk) 01:20, 12 April 2013 (UTC)

From GA24-3312 2821 Unit Description it looks as if the 2821 can be switched under program control, so a system could be symmetric with respect to the unit record equipment attached to a 2821. (Whether any OS supported that is another matter; for example, could a reader or writer task run on arbitrary CPUs and run on CPU 1 at time T and CPU 2 at time T+delta T, or did it require that the task be assigned to a particular CPU?) Guy Harris (talk) 02:01, 12 April 2013 (UTC)

If I read the IBM 2821 manual correctly, no programming effort was needed to use the 2821's two-channel switch. A start I/O issued from either CPU while the control unit is idle is processed the same way as when the switch is not present, and the control unit returns to idle when the operation is complete. The only problem is the unusual addresses of the device. Traditionally the card reader is 00C, the punch 00D and the first printer 00E. The two channel switch requires different addresses, which means the sysgen program won't work since it assumes the traditional addresses. I remember IBM recommending that users with this problem do their sysgen at a data center, but I cannot find a reference for this advice. John Sauter (talk) 12:14, 12 April 2013 (UTC)

For tape drives, IBM offered the 2816 switch. It allowed two systems to share a bank of tape drives by placing a switch between the tape controllers and the tape drives. IBM suggests that this be used for multisystems, not multiprocessors, but it sounds like it should work with a multiprocessor. However, it is hard to see why a customer would want to do it, since it requires adding not only an IBM 2816 switch but also another tape controller. It would be much less expensive to let the operating system issue tape I/O commands from just one CPU, even though that makes the hardware asymmetric. John Sauter (talk) 12:20, 12 April 2013 (UTC)

For any device with multiple channel paths, the I/O Supervisor handles channel selection transparently to the application; neither the readers nor the writers deal with it. See IBM (April 1973). OS I/O Supervisor Logic Release 21 (PDF). Tenth Edition, amended by technical newsletter GN26-8036. IBM. GY28-6616-9. {{cite book}}: Cite has empty unknown parameter: |sectionurl= (help); Unknown parameter |separator= ignored (help) Shmuel (Seymour J.) Metz Username:Chatul (talk) 21:32, 15 July 2013 (UTC)

not obsolete

I did a Google search for asymmetric multiprocessing and found several references since the mid 1980s. I haven't read them yet, but I think there is evidence that the term is still being used. Perhaps the article needs to have a description of how the meaning of asymmetric multiprocessing has changed over time. John Sauter (talk) 01:03, 12 April 2013 (UTC)

PDP-11/74

I noticed that the description of the PDP-11/74 was moved from this article to the symmetric multiprocessing article. However, as the referenced design document mentions, the peripherals were each attached to only one CPU, so the operating system did a “shoulder tap” if necessary to issue an I/O instruction on the correct processor. Doesn't this make the system asymmetric? — Preceding unsigned comment added by John Sauter (talk • contribs) 12:39, 12 April 2013 (UTC)

Sorry, I missed that part. The document says "'Except for devices, which may be distributed among busses, the system is fully symmetrical." The 11/74 sounds similar to the MP 370/168 in that regard. They do explicitly qualify "fully symmetrical" there, so, arguably, it does make the system asymmetric. I'll move it back, with a note that the asymmetry is in access to peripherals.

Perhaps asymmetric multiprocessing should distinguish between systems where one CPU has an inherent role (only one CPU capable of running, or allowed by the OS to run, privileged code, or only one CPU capable of performing, or allowed by the OS to perform, I/O operations) and systems where any CPU can run privileged code and perform I/O but where not all peripherals are directly accessible by all CPUs? Guy Harris (talk) 16:14, 12 April 2013 (UTC)

I agree that there is value in distinguishing these two kinds of asymmetry. There might also be value in describing how much of the kernel runs on the second processor. The B5000 is the only system I am aware of that runs none of the kernel on the second processor, but other early systems ran very little, and later systems, such as the IBM 370/168, ran it all. John Sauter (talk) 20:09, 12 April 2013 (UTC)

I agree that there's value in discussing how much privileged code runs on the second processor. (Were there any systems that had more than one processor and in which there was more asymmetry than "all processors had peripherals other than the console attached to them, but some or all peripherals were attached to only one processor"?) Guy Harris (talk) 21:35, 12 April 2013 (UTC)

I suspect I am misunderstanding your question, because the B5000 and the VAX-11/782 both had more asymmetry: the second processor did no I/O—it did not even have a console. John Sauter (talk) 06:55, 13 April 2013 (UTC)

The question should have been phrased as "...that had more than two processors'...", i.e. you said "second processor", and I was curious whether any systems with three or more processors had a designated processor that was the only processor that could run OS code or the only processor with peripherals attached to it. Guy Harris (talk) 16:49, 13 April 2013 (UTC)

I am aware of only two early multiprocessors which had hardware support for more than two CPUs: the Univac 1108A and the DEC PDP-10. Both used multiported memory so that each CPU and each data channel could have its own access to memory. The Univac used 8-port memory and the PDP-10 used 4-port memory. The Univac required data channels and so could not use all eight ports for CPUs, but the Wikipedia article says that up to 3 CPUs were supported. The PDP-10 did not require data channels, so the hardware supported up to 4 CPUs. However, I never saw a PDP-10 system with more than 2 CPUs, and as far I know only two CPUs were supported by the software. Note that the PDP-10 CPU only had two locations for UUOs to trap to, so supporting more than two CPUs would have been a challenge. John Sauter (talk) 20:44, 13 April 2013 (UTC)

It looks as if the KL10 could, at least in hardware, support up to 3 CPUs Multi-CPU User's Guide, and as if the system didn't have all peripherals attached to all CPUs and had a particular CPU designated as the "policy CPU", although if that CPU became unavailable another one could be chosen by the software (so definitely asymmetric), although it doesn't look like a system where only one CPU can run OS code or do I/O at all. This paper speaks of a 5-CPU KL10 system at Oak Ridge National Laboratory. It also seems to indicate that monitor UUOs trap through an entry in the user process table on the KL10, so there's no two-CPU limitation there. Guy Harris (talk) 21:25, 13 April 2013 (UTC)

These are excellent references for multiprocessing on Tops-10. I had forgotten that user UUOs trap through the user process table, and I never knew that the MH10 had eight ports. Since each KL10 required two ports I don't know how Oak Ridge supported 5 CPUs—perhaps they had special versions of the MH10. Notice that DEC called their multiprocessing SMP, without regard for how I/O devices were attached. I regard the existence of a policy CPU as a programming detail, since if it failed another took over automatically. John Sauter (talk) 13:18, 14 April 2013 (UTC)

strange note

The following note was added at the beginning of the article on January 21: “ (with the exception of the AMIGA The chips in it's chipsets can all be considered "AMP" "Asymetric MultiProcessing" with the COPPER commands as an example of communication between the radically different CPU's.http://www.basden.demon.co.uk/amiga/amiga.diffnt.html#chip.ram )”. The Amiga was not a multiprocessor, and I don't know what the COPPER commands were. I have removed the note since it doesn't seem to make any sense in the context of this article. John Sauter (talk) 13:38, 25 January 2014 (UTC)

The COPPER commands were fairly simple, according to Original Amiga chipset#Copper.

And you are correct, the Amiga is not ASMP in the sense of this article; the name speaks of it as a coprocessor, a concept for which we already have a page. Guy Harris (talk) 18:22, 25 January 2014 (UTC)