JP2000215189A - Multiprocessor computer architecture accompanied by many operating system instances and software control system resource allocation - Google Patents

Abstract

PROBLEM TO BE SOLVED: To obtain a computer system which imparts flexibility, resource usability, and expansibility by providing operating system instances which are executed in different sections. SOLUTION: A multiprocessing computer system 200 divides hardware logically into sections 202, 204, and 206. Hardware elements are assigned so that many operating system instances 208, 210, and 212 can be executed at the same time. This allocation is carried out by console programs 213, 215, and 217. The operating system instances 208, 210, and 212 serve to give the consistency between the resource allocation and sharing by properly using system resources. Serial lines 220, 222, and 224 are connected to a single multiplexer 226 fitted to a workstation 228 to display console information.

Description

DETAILED DESCRIPTION OF THE INVENTION

[0001]

The present invention relates to a multiprocessor computer architecture in which processors and other computer hardware resources are grouped in partitions, each of which has an operating system instance, and more particularly to computer hardware. The present invention relates to a method and apparatus for allocating wear resources to partitions.

[0002]

BACKGROUND OF THE INVENTION Efficient operation of many applications in modern computing environments is dependent on fast, powerful and flexible computing systems. The configuration and design of such a system is dependent on a number of individual departments,
It becomes very complicated when such a system is to be used in a "business" commercial environment where there are a number of different problem types and changing computing needs. Users of such an environment generally desire that the capacity of the system, its speed, and its configuration can be changed quickly and easily.
Users also desire to extend the working capacity of the system and modify its configuration to achieve good use of resources without stopping execution of application programs on the system. In addition, users also want to configure the system to maximize resource utilization so that each application has an optimal computational configuration.

[0003]

Conventionally, the computational speed has been such that "data, business logic, and the graphic user interface are separate connections, each connection having a specific computational resource dedicated to it." do not do"
This was addressed by using a computational architecture.
Initially, a single central processing unit was used, and the power and speed of such computing systems was increased by increasing the clock rate of the single central processing unit. Recently, computing systems have been developed that use multiple processors operating as a team, rather than one size processor operating alone. In this way, rather than waiting for a complex application to be executed by a single processor, it can be distributed among multiple processors. Such systems generally consist of a number of central processing units (CPUs) controlled by a single operating system. In a form of multiprocessor system called "systematic multiprocessing" or SMP, applications are equally distributed across all processors. Processors also share memory. "Non-systematic multi-processing" or A
In another embodiment, referred to as MP, one processor acts as a "master" and all other processors act as "slaves". Therefore, all operations, including the operating system, must be passed to the slave processor after passing through the master. While these multiprocessing architectures have the advantage that performance can be increased by adding additional processors, the software running on such systems must be carefully written to take advantage of the large number of processors. And the difficulty of extending the software as the number of processors increases. The current commercial workload is a single SMP
The system cannot scale beyond 8 to 24 CPUs, the exact number of which depends on the platform,
It depends on a mix of operating systems and applications.

[0004] When it comes to increasing performance, there is another typical answer to dedicate computer resources (machines) to an application and optimally tune machine resources to that application. However, most users do not adopt such a solution because of the large number of applications and separate databases developed by different vendors in most locations. Therefore,
In particular, in an environment where the mix of applications constantly changes, it is difficult and expensive to dedicate resources among all applications. Alternatively, the computer system can be hardware partitioned so that a subset of the resources on the computer can be used for particular applications.
Although this solution avoids permanent dedicating resources because partitions can be changed, problems with performance improvement still remain due to resource load balancing and resource utilization between partitions.

The problem of availability and maintainability is that large centralized, rugged servers containing most resources,
It is addressed by a "share all" model in which a number of small, uncomplicated client network computers are networked and serve them. Alternatively, a "cluster" is used, where each system or "node" has its own memory and is controlled by its own operating system. The systems interact by sharing disks and passing messages between them over some form of communication network. Cluster systems have the advantage that additional systems can be easily added to the cluster. However, networks and clusters
There is a concern that shared memory is scarce and interconnect bandwidth is limited, imposing performance limitations.

It is clear that in many commercial computing environments, two separate computational models must be accepted simultaneously and each model must be optimized. A number of known solutions have been used to attempt such acceptance. For example, a design called "virtual machine" or VM developed and marketed by International Business Machines Corporation of Armonk, NY has one or more physical machines in combination with software that simulates multiple virtual machines. Using a single physical machine with a generic processor. Each of these virtual machines has in principle access to all the physical resources of the underlying real computer. Specifying resources for each virtual machine
It is controlled by a program called "hypervisor". There is only one hypervisor in the system, which is responsible for all physical resources. Therefore, instead of other operating systems,
The hypervisor handles physical hardware allocation. The hypervisor intercepts requests for resources from other operating systems and handles those requests in the overall right way.

[0007] The VM architecture supports the concept of "logical partitions" or LPARs. Each LPAR contains some of the available physical CPUs and resources logically designated for that partition. The same resource can be assigned to more than one partition. The LPAR is set statically by the administrator, but can respond to load changes dynamically and without rebooting in a number of ways. For example, two logical partitions each containing ten CPUs are shared by a physical system containing ten physical CPUs, and the logical ten CPU partitions have complementary peak loads. In such cases, each partition can take over the entire system of 10 physical CPUs without a reboot or operator intervention when the workload shifts.

Further, a CPU logically designated for each partition
Can be dynamically turned "on" and "off" without rebooting via normal operating system operator commands. The only constraint is that the number of CPUs active at system initialization is the maximum number of CPUs that can be turned "on" in any partition. In addition, if the overall workload demand of all partitions is greater than can be provided by the physical system, the LPAR weights are used to determine the total C demand.
It is possible to determine how much of the PU resources are given to each partition. These weights can be changed on the fly by the operator without any obstacles. Another known system is the "Parallel Sysplex.
Sysplex), also developed and marketed by International Business Machine Corporation. This architecture consists of a set of computers clustered through a hardware entity called a "coupling facility" attached to each CPU. The coupling facilities at each node are connected via fiber optic links, and each node has up to ten C
Serves as a conventional SMP machine with a PU. Some CPU
The instructions invoke the coupling facility directly. For example, a node registers a data structure with a coupling facility, and then the coupling facility takes care to keep the data structure coherent in the local memory of each node.

The Enterprise 10,000 Unix Server, developed and marketed by Sun Microsystems of Mountain View, California,
Using a partitioning construct called "Dynamic System Domains", the resources of a single physical server
It is logically divided into a number of partitions or domains, each acting as a standalone server. Each section is a CP
U, memory and I / O hardware. Dynamic reconfiguration allows a system administrator to create, resize, or delete domains on the fly without rebooting. Each domain is
It remains logically isolated from other domains in the system, completely isolating it from software errors or CPU, memory or I / O errors generated by other domains. There is no resource sharing between any domains.

The Hive Project, conducted at Stanford University, uses an architecture organized as a set of cells. As the system boots, each cell is assigned a range of nodes that it owns throughout the run. Each cell manages the processors, memory and I / O devices at these nodes as if it were an independent operating system. These cells work together to give the user-level process a single-system hallucination. The hive cell has no role in determining how to split those resources between local and remote requests. Each cell only serves to maintain its internal resources and optimize its performance within the allocated and source. The overall resource allocation is done by a user level process called "wax". Hive systems attempt to prevent data corruption by using defect-containing boundaries between cells. Resource sharing is implemented by the cooperation of various cell kernels to implement the tight sharing expected from a multiprocessor system despite the defect-containing boundaries between cells, but the policy is that the kernel process in the wax process Implemented outside of Both memory and processor can be shared.

A system called "Cellular IRIX" developed and marketed by Silicon Graphics, Inc. of Mountain View, Calif.
It supports modular computation by extending the traditional systematic multiprocessing system. The cellular IRIX architecture distributes the overall kernel text and data into chunks or "cells" of optimal SMP size. A cell represents a control domain consisting of one or more machine modules, each module consisting of a processor, memory and I / O. Applications running in these cells rely heavily on the entire set of local operating system services, including local copies of operating system text and kernel data structures. Only one instance of the operating system exists in the whole system. Inter-cell alignment allows application images to directly and transparently utilize processing, memory and I / O resources from other cells without incurring data copy or extra context switch overhead.

Another existing architecture, called NUMA-Q, developed and marketed by Sequent Computer Systems, Inc. of Beauverton, Oreg. Is used as a basic building block for NUMA-Q SMP nodes. Adding I / O to each quad further improves performance. Therefore, the NUMA-Q architecture not only distributes physical memory, but also places a predetermined number of processors and PCI slots next to each part. The memory of each quad is not local memory in the conventional sense. Rather, it is one-third of the physical memory address space and has a specific address range. The address map is divided evenly across the memory, each quad including adjacent portions of the address space. Only one copy of the operating system runs and any SMP
As in the system, it is in memory and
Execute processes simultaneously on two or more processors without distinction.

Thus, while many attempts have been made to provide a versatile computer system with maximum resource utilization and scalability, all existing systems have significant drawbacks. Therefore, it is desirable to have a new computer system design that provides improved flexibility, resource availability and scalability.

[0014]

According to the principles of the present invention,
Multiple instances of an operating system run cooperatively on a single multiprocessor computer with all processors and resources electrically connected to each other. A single physical machine with a large number of physical processors and resources
It is adaptively subdivided into multiple partitions, each with the ability to run a separate copy or instance of the operating system. Each partition has access to its own physical resources and resources designated to be shared. 1
According to one embodiment, partitioning of resources is performed by specifying resources within a configuration. More specifically, the software logically and adaptively partitions them by specifying the CPU, memory and I / O ports together. Then, an instance of the operating system is loaded into the partition. At different times, different operating system instances are loaded into a given partition. This partitioning, as dictated by the system manager, is a software function and no hardware boundaries are required. Each individual instance has the resources it needs to run independently. Resources such as CPU and memory are dynamically assigned to different partitions and used by instances of the operating system running in the machine by changing the configuration. Also, the partition itself can be changed without modifying the system by modifying the configuration tree. The resulting adaptively partitioned multi-processing (APMP) system dictates both scalability and high performance.

[0015]

BRIEF DESCRIPTION OF THE DRAWINGS The above and further advantages of the present invention will be better understood from the following detailed description, taken in conjunction with the accompanying drawings, in which: FIG. A computer platform constructed in accordance with the principles of the present invention is a multiprocessor system that can be partitioned to execute multiple instances of operating system software simultaneously. This system does not require hardware support to partition its memory, CPU and I / O subsystem, but uses some hardware to isolate defects and minimize software engineering costs. Additional hardware support may be provided. The interfaces and data structures required to support the software architecture of the present invention are described below. The interfaces and data structures described herein do not imply that a particular operating system must be used, nor that only a single type of operating system will be running at the same time. An operating system that implements the software requirements described below can participate in the system operation of the present invention.

System Building Blocks The software architecture of the present invention uses multiple CPs.
It runs on hardware platforms that incorporate U, memory and I / O hardware. While it is preferred to use a modular architecture as shown in FIG. 1, it will be apparent to those skilled in the art that other architectures can be used, and these architectures need not be modular. FIG. 1 shows a computer system composed of four basic system building blocks (SBBs) 100-106. In the embodiment shown, each building block, such as block 100, is identical, with multiple CPUs 108-114, multiple memory slots (collectively shown as memory 120), and I / O. It has a processor 118 and a port 116 that includes a switch (not shown) that can connect the system to another system. However, in other embodiments, the building blocks need not be identical. By connecting a desired number of system building blocks by these ports, a large multiprocessor system can be configured. Switch technology, rather than bus technology, can be used to connect building block elements to provide improved bandwidth and a non-uniform memory architecture (NUMA).

In accordance with the principles of the present invention, a hardware switch allocates all memory and I / O ports available to each CPU, regardless of the number of building blocks configured schematically as line 122. It is configured to be addressable. In addition, all CPUs have all S
BB can communicate with any or all other CPUs. Thus, CPUs and other hardware resources can relate only to software. Such a platform architecture is inherently scalable, allowing a great deal of processing power, memory and I / O to be obtained on a single computer. An APMP computer system 200 configured in accordance with the principles of the present invention from a software perspective is shown in FIG. In this system, hardware elements are allocated so that multiple operating system instances 208, 210, 212 can run simultaneously.

In a preferred embodiment, this assignment is
It is executed by a software program called a "console" program, which is loaded into memory at power-up, as described in detail below. The console programs are programs 213, 215 and 217.
2 is shown schematically in FIG. The console program is a variant of an existing administrative program or a separate program, which interacts with the operating system to control the operation of the preferred embodiment. The console program does not virtualize system resources, ie, running operating systems 208, 210 and 212, memory and I / O.
It does not form a software layer with physical hardware such as O-units (not shown in FIG. 2). or,
There is no state in which running operating systems 208, 210 and 212 are swapped to access the same hardware. Rather, the system of the present invention
Logically partition hardware into partitions. Operating system instances 208, 210 and 212
Is to use resources appropriately to provide coordination of resource allocation and sharing. The hardware platform can optionally provide hardware support for partitioning resources and minimize the possibility that the operating system will corrupt memory or adversely affect devices controlled by another operating system copy. It can also provide a defect barrier for

The execution environment for a single copy of the operating system, such as copy 208, is a "partition" 2
02, and the running operating system 208 in the partition 202 is the "instance" 20
No. 8. Each operating system instance can boot and run independently of all other operating system instances in the computer system, and cooperate in sharing resources between operating system instances, as described below. You can participate. To run an operating system instance, the partition must be configured with a hardware restart parameter block (HWRP
B), a copy of the console program, an amount of memory, one or more CPUs, and at least one I which must have a dedicated physical port to the console.
/ O bus must be included. HWRPB is a building block passed between the console program and the operating system.

Each of the console programs 213, 215 and 217 is connected to a console port, shown as ports 214, 216 and 218, respectively. Console ports, such as ports 214, 216 and 218, are generally in the form of serial line ports or attached graphics, keyboard and mouse options. In describing the computer system of the present invention,
The ability to support a dedicated graphics port and associated input device is not required, but certain operating systems do. Basic assumption is made that a serial port is sufficient for each partition. Separate terminals or independent graphic consoles can be used to display information generated by each console, but serial lines 220, 222 and a single multiplexer 226 attached to a workstation, PC or LAT 228. Preferably, all 224's can be connected to display console information.

It is important to note that partitions are not synonymous with system building blocks. For example, parcel 202 may correspond to building block 100 of FIG.
, And 106, where partitions 204 and 206 are building blocks 102 and 1 respectively.
04 may be configured. A partition may also include a portion of the building block hardware. A partition can be "initialized" or "uninitialized." The initialized partition has enough resources to run an operating system instance,
It has an image loaded console program and a primary CPU that is usable and executes. The initialized partition may be under the control of a console program or may execute an operating system instance. In the initialized state, the compartment is
It has full ownership and control of the hardware element designated for it, and only the partition itself can release that element.

In accordance with the principles of the present invention, resources can be reassigned from one initialized partition to another. Reassignment of a resource can only be performed in the initialized partition where the resource is currently specified. When one partition is in an uninitialized state, other partitions can reassign the hardware element or delete it. An uninitialized partition is a partition that has no primary CPU that executes under the control of a console program or operating system. For example, a partition may be uninitialized at power-up due to lack of sufficient resources to execute the primary CPU, or may be uninitialized when the system administrator reconfigures the computer system. When in the uninitialized state, one partition can re-designate its hardware elements or the partition can be deleted by another partition. Unspecified resources can be specified by any partition.

Partitions can be organized into underlying "communities" for grouping individual execution contexts to allow cooperative resource sharing. Partitions within the same community can share resources. Partitions that are not in the same community cannot share resources. Resources must be moved manually between partitions that are not in the same community by unassigning (and decommissioning) resources by the system administrator and manually reconfiguring the resources. Communities can be used to form independent operating system domains or to enforce user policies for hardware usage. In FIG. 2, the sections 202 and 204 are organized into a community 230. Partition 206 is in its own community 205. These communities can be formed using the configuration tree described below and can be implemented in hardware.

Console Program When a computer system constructed in accordance with the principles of the present invention is enabled on a platform, multiple HWRPBs must be created, multiple console program copies must be loaded, and each HWRBPB must be loaded. Must specify system resources so that they relate to specific elements of the system. To do this, the first console program to be executed forms in memory a configuration tree structure representing all hardware in the system. The tree also contains software partitioning information and hardware designations for the partitions, which are described in more detail below. More specifically, when the APMP system is powered up, one CPU is selected in a conventional manner as the primary CPU, due to the hardware specific to the platform on which the system is running. The primary CPU then loads a copy of the console program into memory. This console copy is called the "master console"
It is called a program. The primary CPU initially runs under the control of the master console program and performs tests and checks on the assumption that there is a single system that owns the entire machine. Thereafter, a set of environment variables defining the system partition is loaded. Finally, the master console forms and initializes partitions based on environment variables. In this latter process, the master console forms a configuration tree, forms additional HWRPB data blocks, loads additional console program copies, and
It operates to start the CPU in PB. Each partition then has an operating system instance running on it, which cooperates with a console program copy also running on that partition. In an unconfigured APMP system, the master console program initially forms a single partition containing the primary CPU, a minimal amount of memory, and the console of the physical system administrator selected in a platform-specific manner. The console program commands then allow the system administrator to create additional partitions and configure the I / O bus, memory and CPU for each partition.

After the association of resources to partitions is made by the console program, the association is stored in non-volatile RAM so that the system can be automatically configured during subsequent boots. During subsequent boots, the master console program must verify the current configuration with the stored configuration to handle the addition and removal of new elements. Newly added elements are placed in the unspecified state until they are specified by the system administrator. If removing a hardware element leaves the partition with insufficient resources to run the operating system, the resource will continue to be assigned to that partition, but additional new sources will be placed there. The operating system instance cannot run until specified.

As already mentioned, the console program communicates with the operating system instance via HWRPB passed to the operating system during the operating system boot-up. The basic requirement for a console program is that it must be able to form HWRPB itself and multiple copies thereof. Each H formed by the console program
The WRPB copy can boot an independent operating system instance into a private partition of memory, and each operating system instance thus booted can be identified by a unique value placed in HWRPB. This value indicates the partition and is also used as the operating system instance ID.

[0027] In addition, the console program may include a CPU from a CPU available in the partition in response to a request by an operating system running in the partition.
Is configured to form a mechanism for removing Each operating system instance must be able to shut down, shut down or otherwise crash so that control can be passed to the console program. vice versa,
Each operating system instance must be able to reboot to an operating mode independently of the other operating system instances.
Each HWRPB formed by the console program
Is a CPU for each CPU in the system or that can be added to the system without powering down the entire system.
Contains a slot specific database. Each CPU physically present is marked as "present", but only the first CPU executing in a particular partition is
Are marked as “enabled”. An operating system instance running in a partition can determine that the CPU is available at some time in the future by a "Presence" (PP) bit in the per-CPU status flag field of HWRPB, and a data structure representing this. Body can be formed. CPU
"Available" (P
A) The bit, when set, indicates its associated CPU
Is currently associated with the partition and can be guided to add to the SMP operation.

Configuration Tree As already mentioned, the master console program is:
A configuration tree is formed that represents the hardware configuration and the designation of each element of the system for each partition. Each console program then identifies the configuration tree to its associated operating system instance by placing the tree pointer in the HWRPB. Returning to FIG. 3, the configuration tree 300 represents the hardware elements in the system, platform constraints and minimums, and the software configuration. The master console program forms a tree using information stored in non-volatile RAM, including configuration information generated during previous initialization, and information discovered by hardware detection.

The master console can generate a single copy of the tree, where a copy is shared by all operating system instances, or can duplicate the tree for each instance. The disadvantage is that a single copy of the tree can create a single point of failure in systems with independent memory. However, platforms that generate multiple tree copies require that the console program be able to keep changes to the tree synchronized. The configuration tree is made up of a number of nodes, including root nodes, child nodes, and sibling nodes. Each node is formed with a fixed header and a variable length extension to the overlay data structure. The tree starts with a tree root node 302 representing the entire system box, followed by the hardware configuration (hardware root node 304), software configuration (software root node 306), and minimum partition requirements (template root node 308). A branch follows. In FIG. 3, arrows represent child and sibling relationships. The children of a node represent components of the hardware and software configuration. Siblings represent the equivalent of an unrelated element with the same parent. The nodes of the tree 300 include information about software communities and operating system instances, hardware configurations, configuration constraints, performance boundaries, and hot swap capabilities.
These nodes also provide a hardware-to-software ownership relationship or sharing of hardware elements.

These nodes are stored contiguously in memory, and the address offset from the tree root node 302 of the tree 300 to a particular node forms a "handle", which identifies the same element in the operating system instance. Can be used by an operating system instance to clearly identify it. Further, each element of the computer system of the present invention includes:
Has an individual ID. This is a 64-bit unsigned value for explanation. This ID must identify the unique element when combined with the element type and sub-type values. That is, for an element of a given type, the ID must identify the particular element. ID is a simple number,
For example, it could be a CPU ID or some other unique encoding or physical address. The element ID and handle allow any number of computer systems to identify a particular piece of hardware or software. That is, any compartment using any particular method must be able to achieve the same result using the same specifications.

As mentioned above, the computer system of the present invention comprises one or more communities, which in turn comprise one or more partitions. By dividing parcels across independent communities,
The computer system of the present invention can be configured to limit sharing of devices and memory. Communities and parcels have IDs that are densely packed.
The hardware platform determines the maximum number of partitions based on the hardware present in the system, and has a platform maximum limit. Partition and community IDs never exceed this value during runtime. The ID is reused for deleted parcels and communities. The maximum number of communities is the same as the maximum number of parcels. Further, each operating system instance is identified by a unique instance identifier, for example, a combination of a partition ID and a specific number.

The communities and parcels are represented by software root nodes 306, which are children of the community node (whose community node 310 is shown) and parcel node grandchildren (the two nodes 312 and 312).
14 are shown). The hardware element is represented by a hardware root node 304, which includes children indicating a hierarchical display of all hardware currently present in the computer system. The "ownership" of a hardware element is represented by a handle on the relevant hardware node pointing to the appropriate software node (310, 312 or 314). These handles are shown in FIG. 4 and are described below. Elements owned by a particular partition have handles pointing to the nodes representing that partition. Hardware (e.g., memory) shared by multiple partitions has handles that point to the communities whose sharing is bound. Unowned hardware has a zero handle (representing the root node 302).

Hardware elements impose configuration constraints on how ownership is divided. The “config” handle in the configuration tree node associated with each element determines whether the element should be freely associated anywhere in the computer system by pointing to the hardware root node 304. However, certain hardware elements can be bound to an ancestor node and must be configured as part of this node. This example has no restrictions on where to execute, but the SBB32
The CPU is a component of a system building block (SBB) such as 2 or 324. In this case, even if the CPU is a child of SBB,
The nfig handle points to the hardware root node 304. However, the I / O bus cannot be owned by a partition other than the partition that owns the I / O processor. In this case, the configuration tree node representing the I / O bus has a config handle pointing to the I / O processor. Since the rules governing the hardware configuration are platform specific, this information is
Provided to the operating system instance by the g handle.

Each hardware element has an "affinity (affinit
y) "also has a handle. This affinity handle is con
Same as the fig handle, but represents the configuration that gives the best performance of the element. For example, a CPU or memory can be configured anywhere in a computer system.
Having an nfig handle (which points to the hardware root node 304), but for optimal performance, the CPU or memory must be configured to use the system building blocks of which they are a part. As a result, the config pointer points to the hardware root node 304, while the affinity pointer points to node 3
Points to an SBB node such as 22 or 324. The affinity of any element is platform specific and is determined by the firmware. Firmware is “optimal”
Child information can be used when asking to create a simple automatic configuration.

Each node has the form and state of the node.
Also includes a number of flags to indicate. These flags are
Elements that are “hot swappable”
Power down independently of their parents and siblings
Node to indicate Contains the hotswap flag. I
However, all children of this node have this element
If you go down, you have to power down
No. If the child can power down independently of this element
Set this bit at the corresponding node.
Must be Another flag is the node un
available flag, which is set
Then the element represented by the node is currently
Indicates that it is not available. Two flags node
hardware and node template is
Indicate the format of the node. The zone where the node was initialized
Represents the image or represents the CPU that is the current primary CPU.
Node to indicate initializ
ed and node cpu Updates like primary
Can be provided with another flag.

The configuration tree 300 can be extended to the level of a device controller that allows the operating system to form bus and device configuration tables without detecting the bus. However, the tree may end at any level. However, there are cases where all the elements below it cannot be configured independently. System software is still required to detect bus and device information not provided by the tree. The console program executes and enforces any configuration restrictions on each element of the system, if any. In general, an element can be specified without restriction (e.g., the CPU has no restrictions) or can be configured only as part of another element (e.g., a device adapter can only be part of its bus). Configurable). As noted above, partitions that group CPUs, memory, and I / O devices into unique software entities also have minimum requirements. For example, the minimum hardware requirements for a partition include at least one CPU, some private memory (the minimum platform dependent, including console memory), and I / O including a physical non-shared console port. With the bus.

The minimum element requirements for a partition are given by the information contained in the template root node 308.
Template root node 308 includes nodes 316 and 318
And 320, which represent the hardware elements that must be provided to form a partition capable of running console programs and operating system instances. The configuration editor can use this information as a basis to determine what format and how many resources must be available to form a new partition. During the formation of a new parcel, the template subtree is "walked" and for each node of the template subtree,
There must be nodes of the same type and sub-type owned by the new partition to be able to load the console program and boot the operating system instance. If there is more than one node of the same type and sub-type in the template tree, the new partition must also have many nodes. The console program uses the template to verify that the new partition has the minimum requirements before loading the console program and attempting an initialization operation.

A detailed example for a specific implementation of a configuration tree node is provided below. This is merely illustrative and not limiting. Each HWRPB is
It must point to a configuration tree that gives the current configuration and the specification of the elements for the partition. The HWRPB configuration pointer (in the CONFIG field) is used to point to the configuration tree. The CONFIG field points to a 64-byte header that contains the size of the memory pool for the tree and the initial checksum of the memory. Immediately after the header is the root node of the tree. The tree header and root nodes are page aligned. The total size (bytes) of memory allocated to the configuration tree is located in the first quadword of the header. This size is guaranteed to be a multiple of the hardware page size. The second quadword of the header is specified in the check sum. To examine the configuration tree, the operating system instance maps the tree into its local address space. The operating system instance maps this memory with read access granted to all applications, so some configuration to prevent unprivileged applications from gaining access to console data that they should not have access to. Must be provided. Access is limited by the proper allocation of memory. For example, memory may be page aligned and assigned to all pages. Normally,
The operating system instance maps the first page of the configuration tree, gets the tree size, and remaps the memory allocated for use of the configuration tree. The total size may include additional memory used by the console for dynamic changes to the tree. Preferably, the configuration tree node is formed with a fixed header, and optionally includes format-specific information following the fixed header. The size field contains the total length of the node, which is allocated in this example in multiples of 64 bytes and padded as needed. The fields in the fixed header of the node will be described below as an example.

Typedef struct gct node ｛unsigned char type; unsigned char subtype; unit16 size; GCT HANDLE owner; GCT HANDLE current owner; GCT ID id; union ｛unit64 node flags; struct ｛unsigned node hardware: 1; unsigned node hotswap: 1; unsigned node unavailable: 1; unsigned node hw templete: 1; unsigned node initialized: 1; unsigned node CPU primary: 1; #defineNODE HARDWARE 0x001 #defineNODE HOTSWAP 0x002 #defineNODE UNAVAILAVLE 0x004 #defineNODE HW TEMPLATE 0x008 #defineNODE INITIALIZED 0x010 #defineNODE PRIMARY 0x020｝ flag bit;｝ flag union; GCT HANDLE config; GCT HANDLE affinity; GCT HANDLE parent; GCT HANDLE next sib; GCT HANDLE prev sib; GCT HANDLE child; GCT HANDLE reserved; Unit32 magic｝ GCT NODE;

In the above definition, the format definition "unit"
Is an unsigned integer with the appropriate bit length. As described above, the node is positioned by the handle,
Identified (in the above definition, typedef GCT
HANDLE). The handle illustrated here is a signed 32-bit offset from the base of the configuration tree to the node. The values are unique across all partitions of the computer system. That is, the handle obtained in a certain section, in all sections,
Must be valid to look up a node or as input to a console callback. ma
The gic field contains a predetermined bit pattern indicating that the node is actually a valid node. The tree root node represents the entire system. Its handle is always zero. That is, it is always located at the first physical location in memory allocated to the configuration tree following the config header. It has the following definition:

Typedef struct gct root node ｛GCT NODE hd; unit64 lock; unit64 transient level; unit64 current level; unit64 console req; unit64 min alloc; unit64 min align; unit64 base alloc; unit64 base align; unit64 max phys address; unit64 mem size; unit64 platform type; int32 platform name; GCT HANDLE primary instance; GCT HANDLE first free; GCT HANDLE high limit; GCT HANDLE lookaside; GCT HANDLE available; unit32 max partition; int32 partitions; int32 communities; unit32 max platform partition; unit32 max fragments; unit32 max desc; char APMX id [16]; char APMX id pad [4]; int32 bindings;｝ GCT ROOT NODE;

The fields at the root node are defined as follows. lock This field is used as a simple lock by software trying to prohibit changes to the structure of the tree and by software configuration. When this value is -1 (all bits on), the tree is unlocked, and when this value is 0 or greater, the tree is locked. This field is modified using atomic operations. Lock routine caller is block ID
And this is written to the lock field. This can be used to assist defect tracking and recover during a crash. transient level This field is incremented at the beginning of a tree update. current level This field is updated upon completion of the tree update. console req This field specifies the memory (bytes) required for the console in the partition's base memory segment.

Min alloc This field holds the minimum size of the memory fragment and the allocation unit (the fragment size must be a multiple of the allocation). It must be a power of two. min align This field holds an alignment request for a memory fragment. It must be a power of two. base alloc This field contains the minimum memory (bytes) (console) required as the base memory segment for the partition.
req). This is where the console, console structure and operating system are loaded for the partition. This is minal
It must be at least a multiple of loc and minalloc.

Base align This field holds an alignment request for the base memory segment of the partition. It must be a power of two and at least min Must have an align alignment. max phys address This field holds the calculated maximum physical address that may be present in the system including the memory subsystem that is currently powered on and unavailable. mem size This field holds all memory currently in the system. platform type This field stores the platform type obtained from the HWRPB field. platform
name This field represents an integer offset from the base of the tree root node to a string representing the name of the platform. primary instance This field holds the partition ID of the first operating system instance.

First tree This field holds the offset from the tree root node to the first free byte of the memory pool used for the new node. high limit This field holds the highest address where a valid node can be placed in the configuration tree. This is used by the callback to verify that the handle is correct. Lookaside This field is the handle of a linked list of nodes that have been deleted and can be reclaimed. When a community or parcel is deleted, a node is linked to this list, and when a new parcel or community is created, the list is searched prior to assignment from the free pool.

Available This field contains the first Holds the number of bytes remaining in the free pool specified by the tree field. max partitions This field holds the maximum number of partitions calculated by the platform based on the amount of hardware resources currently available.

Partitions This field holds the offset from the base of the root node to the array of handles. Each partition ID is used as an index into this array, and the partition node handle is stored at the indexed location. When a new partition is created, the array is examined to find a first partition ID that does not have a corresponding partition node handle, where the partition ID is the ID for the new partition.
Used as communities This field also holds the offset from the base of the root node to the array of handles. Each community ID
Is used as an index into the array, and the community node handle is stored in the array. When a new community is created, the array is examined to find a first community ID that does not have a corresponding community node handle, and this community ID is used as an ID for the new community. There can be no more communities than parcels, so the array is sized based on the maximum number of parcels.

[0048] max platform partition This field holds the maximum number of platforms that can exist simultaneously on the platform, even if additional hardware is added (potentially in-swapped). max fragment This field holds the platform-defined maximum number of fragments into which a memory descriptor can be split. this is,
Used to determine the array size of the fragment at the memory descriptor node. max desc This field holds the maximum number of memory descriptors for the platform.

APMP id This field holds the system ID set by the system software and saved in non-volatile RAM. APMP id pad This field holds the padding byte of the APMD ID. bindings This field holds the offset for the array of "bindings". Each binding entry describes the type of hardware node, the type of node that must be a parent, the configuration binding, and the affinity binding for the node type. Bindings are used by software to determine how node types are related and the configuration and affinity rules.

Communities provide the basis for sharing resources between partitions. Hardware elements can be specified in any partition of the community, but the actual sharing of devices, such as memory, only occurs within the community. The community node 310 includes a pointer to a control partition called the APMP database, which allows operating system instances to control access and membership in the community for the purpose of sharing memory and communication between instances. APMP
The formation of databases and communities is described in detail below. The configuration ID for the community is a signed 16-bit integer value specified by the console program. The ID value is never greater than the maximum number of compartments that can be formed on the platform.

A partition node, such as node 312 or 314, represents a set of hardware that can execute an independent copy of a console program and an independent copy of an operating system. The configuration ID for this node is a sign month 6-bit integer value specified by the console. This ID is never greater than the maximum number of compartments that can be formed on the platform. A node has the following definition: typedef struct gct partition node ｛GCT NODE hd; unit64 hwrpb; unit64 incarnation; unit64 priority; int32 os type; unit32 partition reserved 1; unit64 instance name format; char instance name [128];｝ GCT PARTITION NODE; The defined fields have the following definitions:

Hwrpb This field holds the physical address of the hardware restart parameter block for this partition. To minimize changes in HWRPB, HWRPB
The RPB does not include a section pointer or section ID. Rather, the partition contains the HWRPB pointer. Therefore, the system software searches for the partition node for the partition containing the physical address of the HWRPB,
The partition ID of the partition where it is executed can be determined. incarnation This field holds a value that is incremented each time the partition's primary CPU performs a boot or restart operation on the partition.

Priority This field holds the priority of the partition. os type This field holds a value indicating the type of operating system to be loaded into the partition.

 ────────────────────────────────────────────────── ─── Continued on the front page (72) Inventor Andrew H Mason United States 03049 Hollis Baxter Road, New Hampshire 61 (72) Inventor Gregory H. Jordan United States New Hampshire 03049 Hollis Jambird Road 22 (72) Inventor Karen El Noel United States New Hampshire State 03275 Pembroke Academy Road 238 (72) Inventor James Earl Kauffman New Hampshire United States 03062 Nashua Norma Drive 31 (72) Inventor Paul Kay Harter Jr. United States of America Massachusetts 01540 Groton Wheely Road 61 (72) Inventor Frederick Keezy Kleinsauga 03031 Amherst Farmington Road, New Hampshire, USA 4 (72) Inventor Stephen F. Sharon 01720 Acton Parker Street 123 F Term, Massachusetts USA 5B045 EE25 GG01 JJ46

Claims (19)

[Claims] 1. A computer system having a plurality of system resources including a processor, a memory, and an I / O circuit, wherein each processor includes all memory and at least some I / O circuits.
An interconnect mechanism for electrically interconnecting the processor, memory and I / O circuits to electrically access the I / O circuit; a software mechanism for dividing system resources into a plurality of partitions; At least one operating system instance running on the partition. 2. The computer system of claim 1, wherein the at least one operating system instance includes at least two operating system instances of different operating systems. 3. The computer system of claim 1, wherein at least some memory is exclusively assigned to each partition. 4. The computer system of claim 1, wherein a plurality of processors are physically divided among the partitions, and each partition includes a console program for controlling a processor of the partition. 5. The computer system according to claim 1, further comprising means for maintaining configuration information indicating which of a plurality of system resources is designated for each partition. 6. One of the processors executes a master console program that generates the configuration information, each partition includes a console program that controls a processor of the partition, and a console program of each partition includes:
6. The computer system according to claim 5, wherein the computer system is provided to communicate configuration information by communicating with a master console program. 7. The computer system of claim 1, wherein said interconnection mechanism includes a switch. 8. A configuration database stored in memory pointing to a partition that is part of the computer system.
A master console including means for forming a configuration database during a power up sequence of the computer system, wherein the configuration database includes information indicating whether each operating system instance is active. Computer system. 9. The operating system instance comprises means for continuously monitoring each other for activity for detecting malfunctions in the operating instance, and each of the operating system instances is connected to another operating system by a heartbeat mechanism. 9. The computer system according to claim 8, comprising means for monitoring an instance. 10. A method for configuring a computer system having a plurality of system resources including a processor, a memory, and an I / O circuit, wherein: (a) each processor electrically connects all memories and at least some I / O circuits; Electrically interconnecting the processor, memory and I / O circuitry to access the: (b) partitioning system resources into a plurality of partitions; and (c) running at least one operating system instance in the plurality of partitions. Performing the method. 11. The method of claim 10, wherein step (c) comprises: (c1) executing at least two different operating system instances in the plurality of partitions. 12. The method of claim 1, wherein step (b) includes (b1) assigning at least some of the memory to each partition.
The method according to 0. 13. The step (b) comprises: (b2) physically dividing the processor between partitions; and (b3) executing a console program at each partition's processor, the console program comprising: 11. The method of claim 10, comprising controlling. 14. The step (b) includes: (b4) specifying a primary processor in each partition; and the step (c) includes: (c1) each operating system in a primary processor of a partition. Run the instance, and (c2)
14. The method of claim 13, including controlling each operating system instance to communicate with a console program for the partition. 15. The method of claim 10, further comprising the step of: (d) maintaining configuration information indicating which of the plurality of system resources is designated for each partition. 16. The step (d) includes: (d2) executing a master console program at one of the processors, the master console program generating configuration information; and (d3) at each partition the processor of the partition. Executing a console program that controls the
The step (d3) further includes: (d3a) communicating with the master console program and exchanging configuration information using the console program of each partition; The method of claim 15, comprising transmitting configuration information to each of the console programs. 17. The step (a) further comprises: (a1) using a switch, a processor, a memory and an I / O
11. The method of claim 10, further comprising the step of interconnecting the / O circuits.
The method described in. 18. The method according to claim 18, further comprising the step of: (e) forming a configuration database containing information regarding which partitions are part of the computer system.
The method of claim 10, further comprising: (e1) forming a configuration database that includes information indicating whether each operating system instance is active. 19. The step (c) further comprises: (c3) using the operating system instance to continuously monitor activities for detecting malfunction of the operating instance by a heartbeat mechanism with respect to each other. 19. The method of claim 18, comprising steps.