U.S. patent application number 11/694339 was filed with the patent office on 2008-10-02 for master and subordinate operating system kernels for heterogeneous multiprocessor systems.
This patent application is currently assigned to Microsoft Corporation. Invention is credited to Haryadi Gunawi, Orion Hodson, Galen C. Hunt.
Application Number | 20080244599 11/694339 |
Document ID | / |
Family ID | 39796587 |
Filed Date | 2008-10-02 |
United States Patent
Application |
20080244599 |
Kind Code |
A1 |
Hodson; Orion ; et
al. |
October 2, 2008 |
Master And Subordinate Operating System Kernels For Heterogeneous
Multiprocessor Systems
Abstract
Systems and methods establish communication and control between
various heterogeneous processors in a computing system so that an
operating system can run an application across multiple
heterogeneous processors. With a single set of development tools,
software developers can create applications that will flexibly run
on one CPU or on combinations of central, auxiliary, and peripheral
processors. In a computing system, application-only processors can
be assigned a lean subordinate kernel to manage local resources. An
application binary interface (ABI) shim is loaded with application
binary images to direct kernel ABI calls to a local subordinate
kernel or to the main OS kernel depending on which kernel
manifestation is controlling requested resources.
Inventors: |
Hodson; Orion; (Redmond,
WA) ; Gunawi; Haryadi; (Madison, WI) ; Hunt;
Galen C.; (Bellevue, WA) |
Correspondence
Address: |
LEE & HAYES PLLC
421 W RIVERSIDE AVENUE SUITE 500
SPOKANE
WA
99201
US
|
Assignee: |
Microsoft Corporation
Redmond
WA
|
Family ID: |
39796587 |
Appl. No.: |
11/694339 |
Filed: |
March 30, 2007 |
Current U.S.
Class: |
718/104 |
Current CPC
Class: |
G06F 9/541 20130101;
G06F 9/5044 20130101; G06F 2209/509 20130101; G06F 9/545
20130101 |
Class at
Publication: |
718/104 |
International
Class: |
G06F 9/46 20060101
G06F009/46 |
Claims
1. A computer-executable method for a computing system that
includes an operating system and multiple heterogeneous processors,
comprising: establishing communication between the processors for
managing resources associated with each processor; receiving a
software application; and allocating different processes of the
software application among the resources of the processors.
2. The computer-executable method as recited in claim 1, wherein
the software application comprises a program selected from a broad
class of programs that includes generic software programs,
commercial software programs, custom software programs, retail
software programs, and off-the-shelf software programs.
3. The computer-executable method as recited in claim 1, wherein
the heterogeneous processors include a main processor and one or
more auxiliary processors; and wherein the operating system runs on
a first subset of the processors that includes the main processor,
and the software application runs on a second subset of the
processors.
4. The computer-executable method as recited in claim 3, wherein
the first and second subsets overlap when some of the processors
run both operating system processes and software application
processes.
5. The computer-executable method as recited in claim 3, wherein
the second subset of processors runs the software application
processes under the management of the operating system.
6. The computer-executable method as recited in claim 3, wherein
the auxiliary processors include programmable GPUs, network
controllers, general purpose CPUs, micro controllers, disk
controllers, RAID controllers, sound processors, and numerical
co-processors.
7. The computer-executable method as recited in claim 3, further
comprising formulating the software application according to a
programming model that enables the software application to run on
the main processor, on one or more of the auxiliary processors, or
on a combination of the main processor and one or more of the
auxiliary processors.
8. The computer-executable method as recited in claim 3, further
comprising converting the software application into instructions
compatible with both the main processor and with the one or more
auxiliary processors when the main processor and at least some of
the auxiliary processors run different instruction set
architectures.
9. The computer-executable method as recited in claim 3, wherein
the first subset of processors running the operating system manages
corresponding local resources associated with the first subset of
processors; and wherein the second subset of processors running the
processes of the software application either manages corresponding
local resources associated with the second subset of processors or
defers the management of at least some of the corresponding local
resources associated with the second subset of processors to the
operating system.
10. The computer-executable method as recited in claim 3, further
comprising running a subordinate kernel agent on the second subset
of processors as a software agent of the operating system that is
running on the first subset of processors, wherein the subordinate
kernel agent is capable of managing computing resources and/or a
memory associated with the second subset of processors and is
capable of thread scheduling on behalf of the second subset of
processors.
11. The computer-executable method as recited in claim 10, wherein
the subordinate kernel agent either: elects to manage some of the
local resources of the second subset of processors and allows the
operating system to manage remaining local resources; or
communicates an inventory of the local resources of the second
subset of processors to the operating system to enable the
operating system to execute a management decision.
12. The computer-executable method as recited in claim 10, wherein
the operating system uses the subordinate kernel agent to perform
an operating system service on the second subset of processors.
13. The computer-executable method as recited in claim 1, wherein
the processors communicate with each other via regions of a memory
of the computing system accessible to both a sending processor and
a receiving processor, wherein inter-processor interrupts signal a
corresponding remote method invocation.
14. The computer-executable method as recited in claim 1, wherein
the processors communicate with each other via a message
transport.
15. The computer-executable method as recited in claim 10, wherein
the operating system launches each process of the software
application on a processor selected by the operating system based
on characteristics of the application, a system configuration
state, and/or a system resource utilization.
16. The computer-executable method as recited in claim 15, wherein
the operating system sends a message to the subordinate kernel
agent indicating where to locate a process image and associated
local resources; and wherein the subordinate kernel agent initiates
the process and notifies the operating system of an outcome of
initiating the process.
17. A computing system, comprising: multiple heterogeneous
processors; an operating system; a multiple processor manager to
establish communication between the processors for managing
computing resources among the processors; and wherein the operating
system allocates processes of a software application among
different processors.
18. The computing system as recited in claim 17, further comprising
a subordinate kernel agent of the operating system to initiate a
process of the software application on one of the processors when
signaled by the operating system.
19. The computing system as recited in claim 18, wherein the
subordinate kernel agent manages computing resources associated
with one or more auxiliary processors in the computing system; and
wherein the one or more auxiliary processors perform a subset of
operating system services on behalf of the operating system.
20. A system, comprising: means for enabling communication between
an operating system of a computing device and multiple processors
of the computing device, such that the multiple processors perform
operating system services for processes of a software application;
and means for assigning processes of the software application among
the multiple processors.
Description
RELATED APPLICATIONS
[0001] This patent application is related to U.S. patent
application Ser. No. 11/005,562 to Hunt et al., entitled,
"Operating System Process Construction," filed Dec. 6, 2004; and
also related to U.S. patent application Ser. No. 11/007,655 to Hunt
et al., entitled, "Inter-Process Communications Employing
Bi-directional Message Conduits," filed Dec. 7, 2004; both of these
related applications are incorporated herein by reference. This
application is also related to U.S. patent application, Attorney
Docket No. MS1-3505US, entitled, "Homogeneous Programming for
Heterogeneous Multiprocessor Systems, filed Mar. 30, 2007, and
incorporated herein by reference.
BACKGROUND
[0002] A computing system that has multiple processors, each
perhaps with different memories and input/output (I/O) bus
locality, may be described as heterogeneous. Besides the main
central processing unit (CPU), auxiliary processors may be present,
such as general purpose CPUs or GPUs, and peripheral processors.
Examples of auxiliary processors residing on peripherals include
programmable GPUs and those on network controllers. Auxiliary
processors may also include general purpose CPUs dedicated to
running applications and not running operating system (OS) code.
Or, they may include processors to be used in low power scenarios,
such as those in certain media capable mobile computers.
Conventional peripheral processors typically run domain-constrained
applications, but have processing power that might be employed for
other tasks.
[0003] Other domains to which peripheral processors are targeted
include video, network control, storage control, I/O, etc. In a
heterogeneous system, the multiple processors may have very
different characteristics. Typically, the processors have different
instruction set architectures. Peripheral processors that enable
ancillary computing functions are often located on physically
separate boards in the computing system or are located on the same
mainboard as the main CPU, but relatively remote in a logical
sense-since they exist in ancillary subsystems. Because peripheral
processors often support different instruction set architectures
than the general purpose CPUs in the system, they interact with the
operating system in a limited manner, through a narrowly defined
interface.
[0004] The various different auxiliary and peripheral processors
(each referred to hereinafter as "auxiliary") usually constitute
resources in a computing system that lie idle at least part of the
time, even when the main CPU is intensively processing under heavy
load-this is because conventional operating systems do not have
enough direct access to the auxiliary processors to delegate
application processing tasks that are usually carried out only by
the main CPU. Each auxiliary processor, in turn, usually has access
to additional local resources, such as peripheral memory, etc.
These additional resources also lie idle most of the time with
respect to the processing load of the main CPU, because they are
not so accessible that the operating system can delegate processing
tasks of the main CPU to them in a direct and practical manner.
SUMMARY
[0005] Systems and methods establish communication and control
between various heterogeneous processors in a computing system so
that an operating system can run an application across multiple
heterogeneous processors. With a single set of development tools,
software developers can create applications that will flexibly run
on one CPU or on combinations of central, auxiliary, and peripheral
processors. In a computing system, application-only processors can
be assigned a lean subordinate kernel to manage local resources. An
application binary interface (ABI) shim is loaded onto
application-only processors with application binary images to
direct kernel ABI calls to a local subordinate kernel or to the
main OS kernel depending on which kernel manifestation is
controlling requested resources.
[0006] This summary is provided to introduce the subject matter of
process and operating system interactions in heterogeneous
multiprocessor systems, which is further described below in the
Detailed Description. This summary is not intended to identify
essential features of the claimed subject matter, nor is it
intended for use in determining the scope of the claimed subject
matter.
BRIEF DESCRIPTION OF THE DRAWINGS
[0007] FIG. 1 is a diagram of an exemplary computing system with
multiple heterogeneous processors and an exemplary process
delegation engine.
[0008] FIG. 2 is a diagram of an exemplary application programming
environment.
[0009] FIG. 3 is block diagram of the exemplary process delegation
engine of FIG. 1, in greater detail.
[0010] FIG. 4 is a block diagram of an exemplary application
install manager of FIG. 3, in greater detail.
[0011] FIG. 5 is a block diagram of the exemplary computing system,
showing grouping of processors into nodes with exemplary
subordinate kernels.
[0012] FIG. 6 is a block diagram of the exemplary subordinate
kernel of FIG. 5, in greater detail.
[0013] FIG. 7 is a diagram of a call function of an exemplary
application binary interface shim to an exemplary subordinate
kernel.
[0014] FIG. 8 is a diagram of a call function of an exemplary
application binary interface shim to a main OS kernel.
[0015] FIG. 9 is a diagram of communication channel assignment
between two application processes.
[0016] FIG. 10 is a diagram of an exemplary remote method
invocation between heterogeneous processors.
[0017] FIG. 11 is a diagram of a processor that is intermediating
communication between two heterogeneous processors.
[0018] FIG. 12 is a flow diagram of an exemplary method of running
an application on multiple heterogeneous processors.
[0019] FIG. 13 is a flow diagram of an exemplary method of creating
an application that is capable of running on multiple heterogeneous
processors.
[0020] FIG. 14 is a flow diagram of an exemplary method of
directing application binary interface (ABI) calls from an
application process running on an application processor.
[0021] FIG. 15 is a block diagram of an exemplary computing
system.
DETAILED DESCRIPTION
[0022] Overview
[0023] This disclosure describes master and subordinate operating
system kernels for heterogeneous multiprocessor systems, including
interactions between the operation system (OS) and application
processes in computing systems that have a heterogeneous mix of
processors--that is, most computing systems.
[0024] FIG. 1 shows an exemplary computing system 100 that includes
an exemplary process delegation engine 102. A detailed description
of such an example computing system 100 is also given for reference
in FIG. 15, and its accompanying description. In the example
systems and methods to be described below, including the exemplary
process delegation engine 102 just introduced, the different
processors 104 found within the wingspan of a typical computing
system 100, such as a desktop or mobile computer, are
communicatively coupled and utilized to run various processes of
software applications that are conventionally limited to running
only on a central or main CPU 106. Communication between the
heterogeneous processors 104 can be realized in different ways,
such as sending and receiving messages via memory regions that are
shared between processors, where messages can be written and an
interrupt assertion mechanism allows the sender to alert the
recipient of the presence of a message in memory. Another mechanism
is a message transport, such as a message bus in which messages can
be exchanged but processors do not necessarily share access to
common memory regions.
[0025] This exemplary delegation of CPU tasks to auxiliary and
peripheral processors 104 provides many benefits. From the
standpoint of the software developer, an application-in-development
written to an exemplary programming model with a single set of
development tools allows the finished application to run flexibly
either on the main CPU 106 only, on auxiliary processors 104 only,
or a combination of the main CPU 106 and some or all of the
auxiliary processors 104.
[0026] From the standpoint of the computing system 100, exemplary
techniques empower the OS to offload application processes from the
main CPU 106 to auxiliary processors 104 that have current capacity
to handle more processing load. Thus, an exemplary system 100
turbo-charges both the software application and the computing
system hardware. The application runs faster and/or more
efficiently. In the context of a laptop, notebook, or other mobile
computing device, the exemplary system may conserve energy, and can
also be used to decrease excess heat production at the main
CPU.
[0027] A compelling example to which the exemplary techniques to be
described below may be applied, is a computing system that includes
a redundant array of storage disks (RAID) storage controller. RAID
storage cards typically have an on-board CPU and memory subsystem
that is used in supervising the replication and reconstruction of
data in the attached RAID array. The CPU is typically a customized
low power general purpose CPU, such as a low power general purpose
CPU or a micro controller, possibly with some additional
instructions targeted at optimizing common RAID controller
operations. A RAID storage controller has locality to the data it
is responsible for, and can potentially run applications that
leverage the data locality. For example, in the context of an
exemplary computing system, the RAID storage controller can run
search services for the data managed by the controller. A search
application running on the controller has the advantage of data
locality and fewer concurrent tasks to run than if running solely
on the main CPU. Similarly, the RAID controller can run the file
system drivers for the file systems stored in the drives attached
to the RAID controller, and remove that responsibility from the
operating system--this can enable fewer context switches in the
general purpose CPUs, leaving them freer for making better progress
on computation tasks.
[0028] Exemplary Software Development System
[0029] FIG. 2 shows exemplary software application development 200.
In one example scenario, an application programming environment 202
adheres to an exemplary programming model 204 that embodies
exemplary techniques and mechanisms for coding an application 206
to run on one or many processors. The term "coding" as used herein
refers to assembling, converting, transforming, interpreting,
compiling, etc., programming abstractions into processor-usable
("native") instructions or language. In one implementation, the
application programming environment 202 produces an application 206
that includes a manifest 208 having a list of resources 210 that
the application 206 can utilize to run, and application code 212.
The application 206 thus created is flexible and via exemplary
techniques or the exemplary process delegation engine 102 can run
214 solely on a single CPU, such as main CPU 106; or can run 216
solely on one or more auxiliary processors 104; or can run 218 on a
combination of the main CPU 106 and at least one of the auxiliary
processors 104.
[0030] In alternative implementations, the process delegation
engine 102 operates on conventional software from a broad class of
off-the-shelf and custom software applications, programs, and
packages. That is, in some implementations, the process delegation
engine 102 can delegate the processes of off-the-shelf software
applications among the multiple heterogeneous processors 104 in a
computing system 100.
[0031] The exemplary application programming model 204 allows the
auxiliary processors 104 to run applications under the control of
the operating system. The exemplary process delegation engine 102
facilitates running a broad class of applications on peripheral
processors and other auxiliary processors 104, thus reducing power
consumption and causing less interruption to the applications that
may be running on the general purpose or main CPU(s) 106.
[0032] Conventionally, vendors do not open processor-containing
entities, such as I/O controllers, for application programming. One
reason is lack of trust that conventional programs will behave in a
memory safe manner. Running third-party applications might corrupt
the memory of the vendor's application and cause the device to
malfunction. The exemplary process delegation engine 102, however,
includes safeguards, such as the type safety verifier 408 and the
memory safety verifier 410 that alleviate these problems. In an
exemplary system, hardware vendors can allow third-party
applications to run on their hardware alongside software that the
vendor provides. The hardware vendor can thus guarantee that
third-party software will not affect the behavior of the software
that is embedded in the hardware system. For instance, with an
exemplary process delegation engine 102, the behavior of firmware
is not affected by third-party applications.
[0033] Even in the face of reliability concerns, some conventional
vendors do open their I/O controllers for application programming
with a proprietary interface. However, this programmability is
rarely used because each application must conventionally be
custom-tailored to the I/O controller's specific hardware and the
vendor's proprietary interface and thus to a different set of
compilers and development tools. In the exemplary application
programming environment 202, however, application code 212 need not
be tailored for a specific I/O controller or a one-off proprietary
operating environment. Instead, application code 212 is written to
the same programming model 204 and interface with the OS using a
common set of development tools regardless of whether the
application will run on a CPU or on an auxiliary processor, such as
an I/O controller.
[0034] Exemplary Engine
[0035] FIG. 3 shows an example version of the process delegation
engine 102 of FIG. 1, in greater detail. The illustrated
implementation is one example configuration, for descriptive
purposes. Many other arrangements of the components of an exemplary
process delegation engine 102 are possible within the scope of the
subject matter. Such an exemplary process delegation engine 102 can
be executed in hardware, software, or combinations of hardware,
software, firmware, etc.
[0036] Although in one implementation it is named "process
delegation engine" 102, the process delegation engine 102 can also
be identified by one of its main components, the exemplary multiple
processors manager 302. The two identifiers go together. From a
functional standpoint, the exemplary process delegation engine 102
manages multiple processors in order to perform process delegation,
and to perform process delegation, the process delegation engine
102 manages multiple processors.
[0037] In the illustrated example, the process delegation engine
102 includes an application install manager 304, in addition to the
multiple processors manager 302. Further, the multiple processors
manager 302 may include an inter-processor communication
provisioner 306, a processor grouper (or group tracker) 308, a
resource management delegator 310, and a subordinate kernel
generator 312.
[0038] The application install manager 304 may further include an
application image generator 314 and a process distributor 316.
Subcomponents of the application install manager 304 will now be
introduced with respect to FIG. 4.
[0039] FIG. 4 shows the application install manager 304 of FIG. 3,
in greater detail. A list of example components is first presented.
Then, detailed description of example operation of the process
delegation engine 102, including the application install manager
304, will be presented. In one implementation, the illustrated
application install manager 304 may use a component or a function
of the available OS wherever possible to perform for the components
named in the application install manager 304. That is, a given
implementation of the application install manager 304 does not
always duplicate services already available in a given operating
system.
[0040] The illustrated application install manager 304 includes a
manifest parser 402, a received code verifier 404, the application
image generator 314 introduced above, the process distributor 316
introduced above, and application (or "process") binary images 406
generated by the other components.
[0041] The received code verifier 404 may include a code property
verifier 407, a type safety verifier 408 and a memory safety
verifier 410. The process distributor 316 may further include a
remote resources availability evaluator 412 and a communication
channel assignor 414.
[0042] The application image generator 314 may further include a
native code compiler 416, a build targets generator 418, an
application binary interface (ABI) shim generator 420, a runtime
library 422, and auxiliary libraries 424. The build targets
generator 418 may further include an instruction stream analyzer
426 and an instruction set architecture targeter 428. The ABI shim
generator 420 may further include an application node type detector
(or tracker) 430.
[0043] Operation of the Exemplary System and Engine
[0044] The exemplary process delegation engine 102 aims to address
control and communication issues between the general purpose main
CPU(s) 106 in a computing system 100 and other auxiliary processors
104 present in the system 100, including processors associated with
peripherals.
[0045] FIG. 5 shows a computing system 100, including a
heterogeneous mix of processors 104 and a main memory 502. The
software of the host operating system (OS) 504 resides in memory
502 and runs on a subset of processors-e.g., an operating system
node 506, grouped or tracked by the processor grouper 308 (FIG. 3).
Applications potentially run on one or more different subset(s) of
processors, such as application nodes 508, 510, 512, and 514. This
nodal grouping of the processors into the operating system node 506
and the various application nodes affects and enhances the
installation of applications, their invocation, and communication
with the operating system and other applications.
[0046] When the processor grouper 308 partitions the processors
into groups or nodes, the operating system node 506 runs the core
operating system 504, including the kernel thread or kernel 516.
The application nodes run applications, as mentioned above. The
terms operating system node 506, application node, and pure
application node may be used to describe the processor groups in
the system. The operating system node 506 is comprised of the
processors running the operating system kernel 516, as mentioned.
Application nodes are groups of processors with similar localities
that are able to run applications. The operating system node 506
may also be an application node. A pure application node, however,
only runs applications. In one implementation, the locality of
resources to each processor is flexible, and there is no need to
specify the ability of the resources to be protected.
[0047] The inter-processor communication provisioner 306 provides
the processors in the heterogeneous computing system 100 with a
means of sending messages to at least one other processor in the
system 100. In one implementation, there is transitive closure in
the messaging paths between processors in the system 100. Sending
and receiving messages may be realized in many ways, depending on
implementation. One mechanism supporting inter-processor messaging
utilizes memory regions that are shared between processors, where
messages can be written and an interrupt assertion mechanism that
allows the sender to alert the recipient of the presence of a
message in memory. Another mechanism is a message bus in which
messages can be exchanged, but processors share access to no common
memory.
[0048] The resource management delegator 310 assumes that the
operating system node 506 always manages the operating system's own
local resources. The operating system 504 manages these system node
resources on behalf of the applications that may run on the
operating system node 506 itself.
[0049] A pure application node, e.g., application node 508, may
manage its own local resources, or it may defer the management to
the operating system 504. The hardware capabilities of a given
application node 508 may constrain the ability of software running
on the node 508 to manage its own resources. The extent of local
resource management on a pure application node 508 may be
determined by the software interface presented by the application
node 508, or may be determined from the outset by the software
system designer, or may be configured dynamically from within the
operating system node 506.
[0050] Resource Management Delegation
[0051] On a pure application node 508, an exemplary software
component referred to herein as a subordinate kernel 518 runs as an
agent of the main operating system 504, for example, by residing in
a local memory 520 and running on a local processor 104'' of the
application node 508. The subordinate kernel 518 may manage
resources associated with the corresponding application node 508,
such as the local memory 520, etc., and may also actively
participate in other local resource management activities, such as
thread scheduling, and directing and running processes of
applications 521 that run mostly or entirely on the application
node 508. In one implementation, the exemplary subordinate kernel
518 is only approximately 1/100 of the data size of the main OS
kernel 516 and runs in a privileged protection domain on the
application node 508. In alternative implementations, the
subordinate kernel 518 can be a process running on the application
node 508 or compiled into a process on the application node
508.
[0052] FIG. 6 shows one implementation of the exemplary subordinate
kernel 518 of FIG. 5, in greater detail. The illustrated
subordinate kernel 518 has a communication channel 602 to the
operating system 504, a local process initiator 604, a software
thread scheduler 606, and a local resource management delegator
608, which may further include a local allocator 610 and an OS
allocator 612.
[0053] A given subordinate kernel 518 may elect to manage a subset
of the local resources associated with its corresponding
application node 508, allotting such management via the local
allocator 610, and may allow the operating system 504 to manage
other resources, allotting these via the OS allocator 612. The
subordinate kernel 518 may also notify the operating system 504 of
its resource allocations via the communication channel 602 to allow
the operating system 504 to make informed management decisions, for
instance, to decide which application node to launch a process on.
These notifications may be sent at the time of resource allocation
change, in an event driven manner, or sent periodically when a time
or resource threshold is crossed.
[0054] The operating system 504 uses the subordinate kernel 518 to
perform operating system services on a pure application node 508
that it could not perform without assistance. For instance, if the
operating system node 506 wants to start a process on the
application node 508, the operating system 504 sends a message to
the subordinate kernel 518 to start the process. The number of
different message types that may be exchanged between the operating
system 504 and subordinate kernel 518 depends on the capabilities
of the subordinate kernel 518, which may very according to
implementation. For instance, if the subordinate kernel 518 does
not support scheduling its own software threads (lacks the software
thread scheduler 606), then the OS-to-subordinate-thread interface
can include thread scheduling methods.
[0055] Application Installation
[0056] Referring back to FIGS. 2-3, in one implementation, an
application 206 is delivered to the operating system 504 as a
package containing the manifest 208, the list of (e.g., "static")
resources used by the application 206, and the application code
212. The manifest 208 describes the resources the application
utilizes from the operating system 504; it's dependencies on other
components, and the resources the application 206 provides.
[0057] In one implementation, the application code 212 is delivered
in an architecture independent form, such as MICROSOFT's CIL
(common intermediate language) for the .NET platform, or JAVA byte
code. The intermediate representation selected should be verifiably
type and memory safe. The operating system 504 may invoke one or
more tools during installation to verify the properties of the
application. The received code verifier 404 (FIG. 4) may check the
code through the code property verifier 407, which has verifiers
for additional static and runtime properties, and through the type
safety verifier 408 and the memory safety verifier 410.
[0058] In one implementation, as managed or executed by the
application install manager 304 (FIGS. 3-4), the operating system's
application installer invokes the native code compiler 416 and the
build targets generator 418 (e.g., a build tool chain) to transform
the independent representation of the application code 212 into
application binaries 406 targeted at the specific instruction set
architectures of the processors 104 that the operating system 504
anticipates the application will run on. The build targets may be
anticipated from the details presented in the manifest 208 and the
properties of the instruction stream.
[0059] The application or process binary images 406 are generated
from the architecture independent application code 212, the
application runtime library 422, additional standard or auxiliary
libraries 424 for the application code 212, and a kernel
application binary interface (ABI) shim 432 generated by the ABI
shim generator 420, which takes into account the type of
application node 508. The standard or auxiliary libraries 424 are
the libraries of routines that the application 206 typically needs
in order to run. The application runtime library 422 provides
data-types and functionality essential for the runtime behavior of
applications 206, for instance, garbage collection. The ABI shim
432 is not typically part of the application binary 406, but a
separate binary loaded into the process along with the application
binary 406.
[0060] Referring to FIGS. 7-8, the kernel ABI shim 432 exports the
corresponding kernel ABI (interface) 702 and is responsible for
handling requests to the operating system 504. The application
image generator 314 (FIGS. 3-4) creates at least one kernel ABI
shim 432 for each type of application node 508 (e.g., pure or OS)
that exists in the system 100. First degree processors, such as the
main CPU 106 that runs both the OS and applications may receive one
build of the ABI shim 432 while second degree processors, such as
the auxiliary processors 104, may receive a different build of the
ABI shim 432. For example, the install manager 304 may create an
ABI shim 432 for each type of I/O processor 104 under management of
the process delegation engine 102. For an application 206 running
on the operating system node 506, the corresponding ABI shim 432
makes calls to the operating system kernel 516 through the kernel
ABI 702.
[0061] As shown in FIG. 7, for applications 206 running on a pure
application node 508, the ABI shim 432 calls to the local
subordinate kernel 518 when the ABI call 704 relates to resources
managed by the subordinate kernel 518.
[0062] As shown in FIG. 8, the ABI shim 432 performs remote method
invocations on the operating system node 506 for ABI calls 704 that
cannot be satisfied by the subordinate kernel 518 on the
application node 508. For instance, if the subordinate kernel 518
has its own thread scheduler 606 then the ABI shim 432 need not
remote the calls relating to scheduling to the operating system
node 506; and conversely, if the application node 508 has no
scheduling support, then the ABI shim 432 makes remote procedure
calls to the operating system node 506 each time a
scheduling-related ABI call 704 is made.
[0063] Inter-Process Communication
[0064] Processes in the exemplary computing system 100 may run on
either the operating system node 506 or on an application node 508.
Processes use the kernel ABI shim 432 to communicate with the
operating system kernel 516 and, as shown in the channel
communication mechanism 900 of FIG. 9, processes use a
bidirectional typed channel conduit 902 to communicate with other
processes, according to a bidirectional channel scheme described in
U.S. patent application Ser. No. 11/007,655 to Hunt et al.,
entitled, "Inter-Process Communications Employing Bi-directional
Message Conduits" (incorporated herein by reference, as introduced
above under the section, "Related Applications").
[0065] In one implementation, the exemplary kernel ABI shim 432 is
a library that may be statically compiled into an application image
406 or dynamically loaded when the application 206 starts. In one
implementation, the kernel ABI shim 432 and channel communication
mechanism 900 are the only two communication mechanisms available
to a process: thus, applications 206 are protected from each other
by the memory and type safety properties of the process and the
restrictions imposed by the kernel ABI 702 design and channel
communication mechanism 900.
[0066] The kernel ABI shim 432 may call directly into the operating
system kernel 516 when a node 506 running the process is also the
operating system node 506. When running on a pure application node
508, the kernel ABI shim 432 may use a remote procedure call to
invoke the kernel call on the operating system node 506. In systems
where the application node 508 has some autonomy over its resource
management, the kernel ABI shim 432 directs calls relating to
resources it manages to the application node subordinate kernel
518. The kernel ABI shim 432 exports the same methods as the kernel
ABI 702. As mentioned above, from the application software
developer's perspective there is no difference in the source code
based on whether the application will run on the operating system
node 506 or on one or more application node 508--the interface of
the kernel ABI shim 432 is indistinguishable from the kernel ABI
702.
[0067] In exemplary implementations, the kernel ABI 702 contains
methods that only affect the state of the calling process-there are
no calls in the ABI 702 that a process can use to affect the state
of another process, except to terminate a child process. And in one
implementation of the kernel ABI 702, the operating system kernel
516 provides no persistent storage of state that two processes
could use to exchange information, and thus precludes the use of
the ABI 702 to exchange covert information.
[0068] In FIG. 9, messages between processes are exchanged through
bi-directional message conduits 902 with exactly two endpoints. The
channels 902 provide a lossless first-in-first-out message delivery
system. The type and sequence of messages exchanged between two
endpoints is declared in a channel contract. When a process starts,
the operating system 504 provides the process with an initial set
of channel endpoints, e.g., via the communication channel assignor
414. The process being initialized is only able to communicate with
processes holding the other endpoints associated with the channel
902.
[0069] Messages sent over channels 902 may have associated
arguments. In one implementation, message arguments may contain
permitted: value types, linear data pointers, and structures
composed of value types and linear data pointers. Messages may not
contain pointers into the sending process's memory address space.
Endpoints may be passed between processes within a channel 902. The
type constraint on message arguments maintains the isolation of
memory spaces between processes. Thus, there is no way for two
processes to exchange data without using channels 902,
[0070] When an application 206 is running on the operating system
node 506, an ABI shim 432 is not necessary as the application 206
may call directly to the operating system kernel 516. When an
application running on the operating system node 506 needs to make
a channel call, it may use the native implementation of channels
used on the system for uniprocessor and symmetric multiprocessor
configurations.
[0071] When an application 206 running on a pure application node
508 needs to make a channel call or a kernel ABI call 704 to the
operating system node 506, a remote method invocation may be used.
A remote method invocation is also necessary when any two
applications running on different nodes need to communicate with
each other over channels 902, and also when the operating system
504 needs to call to a pure application node 508. On a pure
application node 508, an ABI call 704 is similar to a channel call,
with the difference that an ABI call 704 is directed to only one
node, the operating system node 506, whereas the other endpoint of
a channel 902 may be located on any node in the system 100.
[0072] The execution of the remote method invocation is realized
according to the connectivity between processors 104 in the system.
As shown in FIG. 10, in one implementation, realization of remote
method invocation uses a memory region 1002 accessible to both
caller and callee to hold a message state, and uses inter-processor
interrupts 1004 to signal the arrival of a remote method
invocation. The callee unmarshals the arguments, executes the
request, marshals the response data into another portion of the
shared memory region 1002, and then sends an inter-processor
interrupt 1006 to signal the arrival of the response.
[0073] In one implementation, the caller aims to know or be able to
determine the appropriate lower level transport, transport
settings, and how to marshal the method and arguments. This
information is usually determined through a resolution mechanism.
In a typical situation, a pure application node 508 knows at least
one well-known node, such as the operating system node 506, and
knows the appropriate method of contacting that node 506. The pure
application node 508 and its well-known node 506 use a resolver
protocol to resolve callee and method. The well-known target(s)
help in the resolution of caller and method into an actionable
response.
[0074] As shown in FIG. 11, in the case that two applications
(running on distinct pure application nodes, such as application
nodes 510 and 1102) wish to send channel messages to each other,
they sometimes may not have a direct conduit for doing so. However,
the message may be relayed between the application nodes (510 and
1102) via one or more intermediary nodes 1104, which may also apply
the resolver protocol 1106 described above. In one implementation,
the operating system node 506 communicates with each application
node (510 and 1102), and can act as intermediary between
application nodes in the absence of a direct path between them.
[0075] Application Processes
[0076] In one implementation, the operating system node 506 is
responsible for launching processes on the application nodes (e.g.,
508) in the system 100. The operating system 504 is aware of each
and every installed application 206 and its resource requirements.
When a process starts, the operating system 504 decides on a node
to launch the application. This decision may be based upon
information in the application manifest 208, system configuration
state, and/or may be made dynamically based on system resource
utilization.
[0077] When a process is started on the operating system node 506,
the process typically requires no steps in addition those for the
conventional launch of a process in a conventional operating
system. When a process is to be started on a pure application node
508, the operating system 504 initiates the process. The operating
system 504 need only send a message to the local process initiator
604 in the local subordinate kernel 518 on the node 508, informing
the node 508 where to locate the process image 406 and
corresponding resources. The subordinate kernel 518 then becomes
responsible for starting the process and notifies the operating
system kernel 516 of the outcome of the process initialization
process. In one implementation, the subordinate kernel 518 itself
is also started during the initialization of the application node
508. The subordinate kernel 518 instruction stream may be present
in non-volatile storage associated with the node 508 or it may be
loaded into the memory associated with the application node 508 by
the operating system node 506 when the operating system node 506
initializes the application node 508.
[0078] Exemplary Methods
[0079] FIG. 12 shows an exemplary method 1200 of running an
application on multiple heterogeneous processors. In the flow
diagram, the operations are summarized in individual blocks. The
exemplary method 1200 may be performed by hardware, software, or
combinations of hardware, software, firmware, etc., for example, by
components of the exemplary process delegation engine 102.
[0080] At block 1202, communication is established between the
processors for managing resources associated with each processor.
Conventionally, two processors in a computing system may or may not
communicate with each other. For example, two far-flung processors
on peripheral plug-in cards may not communicate directly with each
other at all. But exemplary communication between all relevant
processors in computing system can be achieved in a practical
sense--for purposes of deciding management of computing resources.
Some processors can communicate with each other by leaving messages
in a memory region and then using processor interrupts to signal
the other processor of the message's presence. Subordinate
"pared-down" kernels of the operating system can be associated with
groups of auxiliary and peripheral processors to communicate with
the main OS kernel and manage local resources. Communication is
thus set up between multiple heterogeneous processors in a
computing system so that the operating system can discern what
computing resources are available across the heterogeneous
processors and whether the OS itself is managing a given resource
or whether an assigned subordinate kernel is instead managing the
given resource on a more local level.
[0081] At block 1204, a software application is received. In one
implementation, the software application is designed with a
manifest and a list of likely resource needs so that the operating
system can efficiently allocate processes of the application among
the multiple heterogeneous processors However, in another
implementation, a stock or off-the-shelf application is received
that is agnostic to the method 1400 of running an application on
multiple heterogeneous processors.
[0082] At block 1206, different processes of the software
application are allocated among the resources of the processors. In
one implementation, the application is transformed into neutral or
generic binary images that can be run on one processor or
many--given the communication established between heterogeneous
processors and their heterogeneous resources.
[0083] FIG. 13 shows an exemplary method 1300 of creating an
application capable of running on multiple heterogeneous
processors. In the flow diagram, the operations are summarized in
individual blocks. The exemplary method 1300 may be performed by
hardware, software, or combinations of hardware, software,
firmware, etc., for example, by components of the exemplary process
delegation engine 102.
[0084] At block 1302, an application is received. The application
may be designed with an exemplary manifest and list of likely
needed resources, or the application may be received as-is,
off-the-shelf in conventional form, as described above in the
previous method 1200.
[0085] At block 1304, the application is coded so that the
application is capable of running either solely on a main
processor, solely on one or more auxiliary processors, or on a
combination of the main processor and one or more auxiliary
processors. The application can exist in an architecture
independent form, and be further transformed into a neutral or
generic code so that the application will run on one or many
processors. The intermediate representation is preferably type and
memory safe. The operating system may verify the properties of the
application.
[0086] In one implementation, the operating system's application
installer invokes a native code compiler and a build tool chain to
transform the application code into application binaries targeted
at the specific instruction set architectures of the processors
that the operating system anticipates the application will run on.
The build targets may be anticipated from the details presented in
a manifest and/or properties of the instruction stream.
[0087] In one implementation, the application or process binary
images are generated from architecture independent application
code, and from a runtime library and additional standard or
auxiliary libraries. Coding the application into binaries may
include creating a kernel application binary interface (ABI)
shim--usually a separate binary--that takes into account the type
of application node target that will run the application binary
image.
[0088] FIG. 14 shows an exemplary method 1400 of directing
application binary interface (ABI) calls to enable an application
to run on multiple heterogeneous processors. In the flow diagram,
the operations are summarized in individual blocks. The exemplary
method 1400 may be performed by hardware, software, or combinations
of hardware, software, firmware, etc., for example, by components
of the exemplary process delegation engine 102.
[0089] At block 1402, an ABI shim makes an ABI call for a resource.
That is, a process of an application running, e.g., on a pure
application processing processor, or group of processors calls for
a resource via the kernel ABI. The ABI shim, compiled into the
application binary that is running, can direct its call depending
on which kernel manifestation is managing the resource being
requested,
[0090] At block 1404, locality of the resource's managing entity is
tested. The ability to detect which kernel manifestation--main OS
kernel or an exemplary subordinate kernel--is controlling a given
resource can be fixed into the ABI shim during its creation, if
management of certain resources is static and known at the time of
ABI shim generation. Or, a particular ABI shim may include routines
to detect dynamically-changing management of a given resource.
[0091] At block 1406, the ABI shim calls to a local subordinate
kernel when the ABI call relates to resources managed by the
subordinate kernel. That is, the ABI shim calls locally to the
local subordinate kernel rather than call the main OS kernel, if
management has been assigned to the local kernel. To the calling
application process, the ABI shim is transparent. No matter where
the ABI shim calls, the ABI shim presents the same kernel ABI
appearance to the running application process.
[0092] At block 1408, the ABI shim performs remote method
invocations on the operating system's main kernel for ABI calls
that cannot be satisfied by the subordinate kernel. That is, if a
called resource is not under control of the local node of
application-processing processors, then the ABI shim invokes the
main OS kernel, which is typically managing the called resource if
the local subordinate kernel is not.
[0093] Exemplary Computing Device
[0094] FIG. 15 shows an exemplary computing system 100 suitable as
an environment for practicing aspects of the subject matter, for
example to host an exemplary process delegation engine 102. The
components of computing system 100 may include, but are not limited
to, a processing unit 106, a system memory 502, and a system bus
1521 that couples various system components including the system
memory 502 and the processing unit 106. The system bus 1521 may be
any of several types of bus structures including a memory bus or
memory controller, a peripheral bus, and a local bus using any of a
variety of bus architectures. By way of example, and not
limitation, such architectures include Industry Standard
Architecture (ISA) bus, Micro Channel Architecture (MCA) bus,
Enhanced ISA (EISAA) bus, Video Electronics Standards Association
(VESA) local bus, and Peripheral Component Interconnect (PCI) bus
also known as the Mezzanine bus.
[0095] Exemplary computing system 100 typically includes a variety
of computing device-readable media. Computing device-readable media
can be any available media that can be accessed by computing system
100 and includes both volatile and nonvolatile media, removable and
non-removable media. By way of example, and not limitation,
computing device-readable media may comprise computing device
storage media and communication media. Computing device storage
media include volatile and nonvolatile, removable and non-removable
media implemented in any method or technology for storage of
information such as computing device-readable instructions, data
structures, program modules, or other data. Computing device
storage media includes, but is not limited to, RAM, ROM, EEPROM,
flash memory or other memory technology, CD-ROM, digital versatile
disks (DVD) or other optical disk storage, magnetic cassettes,
magnetic tape, magnetic disk storage or other magnetic storage
devices, or any other medium which can be used to store the desired
information and which can be accessed by computing system 100.
Communication media typically embodies computing device-readable
instructions, data structures, program modules or other data in a
modulated data signal such as a carrier wave or other transport
mechanism and includes any information delivery media. The term
"modulated data signal" means a signal that has one or more of its
characteristics set or changed in such a manner as to encode
information in the signal. By way of example, and not limitation,
communication media includes wired media such as a wired network or
direct-wired connection and wireless media such as acoustic, RF,
infrared and other wireless media. Combinations of any of the above
should also be included within the scope of computing device
readable media.
[0096] The system memory 502 includes or is associated with
computing device storage media in the form of volatile and/or
nonvolatile memory such as read only memory (ROM) 1531 and random
access memory (RAM). A basic input/output system 1533 (BIOS),
containing the basic routines that help to transfer information
between elements within computing system 100, such as during
start-up, is typically stored in ROM 1531. RAM system memory 502
typically contains data and/or program modules that are immediately
accessible to and/or presently being operated on by processing unit
106. By way of example, and not limitation, FIG. 15 illustrates
operating system 504, application programs 206, other program
modules 1536, and program data 1537. Although the exemplary process
delegation engine 102 is depicted as software in random access
memory 502, other implementations of an exemplary process
delegation engine 102 can be hardware or combinations of software
and hardware.
[0097] The exemplary computing system 100 may also include other
removable/non-removable, volatile/nonvolatile computing device
storage media. By way of example only, FIG. 15 illustrates a hard
disk drive 1541 that reads from or writes to non-removable,
nonvolatile magnetic media, a magnetic disk drive 1551 that reads
from or writes to a removable, nonvolatile magnetic disk 1552, and
an optical disk drive 1555 that reads from or writes to a
removable, nonvolatile optical disk 1556 such as a CD ROM or other
optical media. Other removable/non-removable, volatile/nonvolatile
computing device storage media that can be used in the exemplary
operating environment include, but are not limited to, magnetic
tape cassettes, flash memory cards, digital versatile disks,
digital video tape, solid state RAM, solid state ROM, and the like.
The hard disk drive 1541 is typically connected to the system bus
1521 through a non-removable memory interface such as interface
1540, and magnetic disk drive 1551 and optical disk drive 1555 are
typically connected to the system bus 1521 by a removable memory
interface such as interface 1550.
[0098] The drives and their associated computing device storage
media discussed above and illustrated in FIG. 15 provide storage of
computing device-readable instructions, data structures, program
modules, and other data for computing system 100. In FIG. 15, for
example, hard disk drive 1541 is illustrated as storing operating
system 1544, application programs 1545, other program modules 1546,
and program data 1547. Note that these components can either be the
same as or different from operating system 504, application
programs 206, other program modules 1536, and program data 1537.
Operating system 1544, application programs 1545, other program
modules 1546, and program data 1547 are given different numbers
here to illustrate that, at a minimum, they are different copies. A
user may enter commands and information into the exemplary
computing system 100 through input devices such as a keyboard 1548
and pointing device 1561, commonly referred to as a mouse,
trackball, or touch pad. Other input devices (not shown) may
include a microphone, joystick, game pad, satellite dish, scanner,
or the like. These and other input devices are often connected to
the processing unit 106 through a user input interface 1560 that is
coupled to the system bus, but may be connected by other interface
and bus structures, such as a parallel port, game port, or a
universal serial bus (USB). A monitor 1562 or other type of display
device is also connected to the system bus 1521 via an interface,
such as a video interface 1590. In addition to the monitor 1562,
computing devices may also include other peripheral output devices
such as speakers 1597 and printer 1596, which may be connected
through an output peripheral interface 1595.
[0099] The exemplary computing system 100 may operate in a
networked environment using logical connections to one or more
remote computing devices, such as a remote computing device 1580.
The remote computing device 1580 may be a personal computing
device, a server, a router, a network PC, a peer device or other
common network node, and typically includes many or all of the
elements described above relative to computing system 100, although
only a memory storage device 1581 has been illustrated in FIG. 15.
The logical connections depicted in FIG. 15 include a local area
network (LAN) 1571 and a wide area network (WAN) 1573, but may also
include other networks. Such networking environments are
commonplace in offices, enterprise-wide computing device networks,
intranets, and the Internet.
[0100] When used in a LAN networking environment the exemplary
computing system 100 is connected to the LAN 1571 through a network
interface or adapter 1570. When used in a WAN networking
environment, the exemplary computing system 100 typically includes
a modem 1572 or other means for establishing communications over
the WAN 1573, such as the Internet. The modem 1572, which may be
internal or external, may be connected to the system bus 1521 via
the user input interface 1560, or other appropriate mechanism. In a
networked environment, program modules depicted relative to the
exemplary computing system 100, or portions thereof, may be stored
in the remote memory storage device. By way of example, and not
limitation, FIG. 15 illustrates remote application programs 1585 as
residing on memory device 1581. It will be appreciated that the
network connections shown are exemplary and other means of
establishing a communications link between the computing devices
may be used.
[0101] Conclusion
[0102] Although exemplary systems and methods have been described
in language specific to structural features and/or methodological
acts, it is to be understood that the subject matter defined in the
appended claims is not necessarily limited to the specific features
or acts described. Rather, the specific features and acts are
disclosed as exemplary forms of implementing the claimed methods,
devices, systems, etc.
* * * * *