Computer system for unified memory access

Abstract

The application provides a computing system 100 for uniform memory access, comprising: a first processing unit 101 and a second processing unit 102; a shared memory 103, comprising a first memory segment 104 and a second memory segment 105; an operating system 106, at least partially operated by the first processing unit 101; an application 107, at least partially operated by the operating system 106. The first processing unit 101 and the second processing unit 102 are connected to the shared memory 103. The operating system 106 is configured to: based on requirement information included in the operating system 106 and / or the application 107, control at least one of the first processing unit 101 and the second processing unit 102 and the shared memory 103, so as to allocate the first memory segment 104 to at least part of the application 107, wherein the requirement information comprises executable binary code, and wherein the executable binary code comprises information of a type of a required memory segment of at least part of the application 107 and / or information of a type state of the required memory segment of at least part of the application 107.

Description

TECHNICAL FIELD

[0001] The present invention relates to a computing system for unified memory access and a corresponding method. In particular, the system and method of the present invention affect the way an operating system (OS) allocates shared memory in a multi-processor system based on demand information. Preferably, the demand information comprises executable binary code including information on the type and / or state of at least a portion of the memory segment required by an application. BACKGROUND

[0002] Emerging computer architectures are characterized by an increasing heterogeneity of memory and processor subsystems, mainly due to novel memory technologies, low-latency load / store access interconnects and the resurgence of near data processing (NDP), which introduces processing units along the memory hierarchy.

[0003] Addressable memory includes on-chip memory, off-chip memory (e.g. common DIMM modules) or remote machine memory. Moreover, with the advent of storage class memory (SCM), addressable memory can be volatile or persistent. To enable low-latency memory-mapped communication within a machine, new interconnects are being developed, including CCIX, Gen-Z, OpenCAPI or Serial Memory Bus. A unifying feature beyond these technologies is to provide a shared memory interconnect between all components within a system, either based on a single node, or at the rack level. Some features also aim at providing hardware-based cache coherency. Finally, NDP is gaining attention due to technology innovations. NDP is the co-location of processing and memory, in the form of processing in memory (PIM) or in-storage processing (ISC).

[0004] The above technologies enable different types of processing units to access the same memory simultaneously. Figure 8 A scenario is illustrated where a main memory is accessed by near data processors, CPUs connected to a coherent interconnect, accelerators interconnected to CPUs via a peripheral bus and remote processing units (e.g. near data processors, CPUs or GPUs) connected via an RDMA-enabled interface. The accelerator-CPU-NIC setup is a sub-scenario of the above technologies, where an accelerator (FPGA, GPU or Xeon-Phi), a CPU and a NIC share one common memory region. With the increase of NDP and rack-level computing, the number of processing units accessing the same memory region also steadily increases. Moreover, all memory becomes load / store accessible, both inter-machine and intra-machine.

[0005] It can be found that the prior art is evolving towards multiple-kernel OS or multiple OS / Run Managers accessing the same memory region. In addition, the traditional OS architecture does not take into account memory heterogeneity, except for (non-cacheable) cacheable regions and non-uniform memory access (NUMA).

[0006] In traditional computing systems, applications are statically compiled for one computer platform and thus conform to a specific homogeneous memory model. However, the same memory region can be accessed by processors with different instruction set architectures (ISAs) and consistency models and providing different synchronization mechanisms.

[0007] In order to fully support emerging architectures where multiple processing units access the same memory region simultaneously, different system software constructs are required to enable format-compatible data sharing between different (OS-enabled) ISA processors, consistent memory access (based on application programmer's expectations), protection between processors, transparency to programmers, and development of efficient communication.

[0008] These prior art solutions raise the question of how system software can efficiently and effectively manage shared memory between different computing units in the system.

[0009] The prior art solutions deal with the heterogeneity of memory and processing units relatively statically. The programmer needs to prepare the software in advance for a specific target architecture, possibly using a specialized programming model to explicitly address consistency and incompatibility issues that arise due to heterogeneity. Using heterogeneous accelerators also involves explicit programming, for example, through a certain domain-specific accelerator language. Furthermore, the potential advantages of heterogeneity cannot be fully exploited at runtime, as these advantages need to be explicitly addressed at programming and application development time, reducing the opportunity for further optimization.

[0010] The drawbacks of the prior art solutions are that they force the application developer to adopt a specific programming model, require modification of the software, are targeted at a specific heterogeneous environment, exclude the possibility of running in several potentially available accelerator environments that can be co-hosted, and prohibit optimization opportunities that can be determined at application runtime. SUMMARY

[0011] In view of the above problems and drawbacks, the present application aims at improving the traditional systems and methods. Therefore, the object of the present application is to provide a system that overcomes the heterogeneity drawback in emerging computer architectures. By providing a combination of compile-time mechanisms and run-time mechanisms at the operating system and application level, the programmer does not have to design the application for a specific heterogeneous platform. Therefore, the memory access in a heterogeneous environment can be unified. By avoiding the redesign of legacy applications to further exploit the advantages of a heterogeneous platform, this also enables backward compatibility of legacy applications. The operating system is also opened to make run-time decisions that actively exploit the advantages of the heterogeneous devices (e.g. by scheduling and transparent migration of processes that have better performance and efficiency when and where), without requiring explicit involvement at the time of application development.

[0012] In particular, the present application proposes a solution that uses "memory contracts" (also referred to as requirement information) as a system software solution, created at compile time by the compiler or linker, implemented at runtime by the operating system. From the memory contracts, checks can be made at runtime, such as checking the consistency, protection or consistency guarantees that the code acting on a memory region must respect.

[0013] The memory contracts can include an enhanced executable binary format, extended to maintain metadata sections. The metadata sections include memory consistency, ISA and application binary interface (ABI) requirements. Therefore, the traditional OS binary loader can be enriched to recognize the metadata sections and load them at runtime. Moreover, the OS is opened to dynamically select the matching contract at runtime for the various possible processing elements present in the heterogeneous computing architecture, and in addition to transparently migrate tasks (processes, threads) from the user to any processing unit, thus unifying the access to the memory.

[0014] Therefore, the present application solves the problem that in the prior art the application writers do not have to adopt a specific programming model in order to use the heterogeneous resources. The application is opened to exploit several available heterogeneous resources, instead of being targeted to a specific resource. The operating system is opened to make dynamic decisions at runtime transparently, thus better exploiting the available heterogeneous resources.

[0015] The objects of the present application are achieved by the solutions provided in the appended independent claims. Advantageous embodiments of the present application are further defined in the dependent claims.

[0016] The first aspect of the present application provides a computing system for uniform memory access, comprising: a first processing unit and a second processing unit; a shared memory, comprising a first memory segment and a second memory segment; an operating system, operated at least partly by the first processing unit; an application, operated at least partly by the operating system; wherein the first processing unit and the second processing unit are connected to the shared memory; wherein the operating system is configured to: based on requirement information included in the operating system and / or the application, control at least one of the first processing unit and the second processing unit and the shared memory, so as to allocate the first memory segment to at least a part of the application, wherein the requirement information comprises executable binary code, wherein the executable binary code comprises information of type and / or state of memory segment required by at least a part of the application.

[0017] As the memory access can be made according to the requirement information included in the operating system and / or the application, the programmer does not need to design the application for a specific heterogeneous platform. In addition, the operating system is enabled to make runtime decisions regarding memory access, actively taking advantage of the strengths of the heterogeneous devices. The OS is enabled to effectively and efficiently control the heterogeneous processing units and / or the heterogeneous memory segments when running the application.

[0018] In a first implementation form of the system according to the first aspect, the first processing unit and the second processing unit have different processing unit architectures.

[0019] This ensures that the memory access can be unified, in particular in a heterogeneous computing system, more specifically in a system in which the first computing unit and the second computing unit have different architectures.

[0020] In a second implementation form of the system according to the first aspect, the requirement information further comprises first requirement information, wherein the first requirement information is related to properties of executable binary code of at least a part of the application, and the operating system is further configured to: based on the first requirement information, control at least one of the first processing unit and the second processing unit and the shared memory, so as to allocate the first memory segment to at least a part of the application.

[0021] This ensures that, when operating the computing system, the properties of the executable binary code of at least a part of the application can be taken into account in particular for unifying the memory access.

[0022] In a third implementation form of the system according to the first aspect as such, the first requirement information is executable binary code comprising information about an application binary interface, ABI, used for compiling at least one part of the application, and / or a format used for compiling at least one part of the application, and / or a persistence property, and / or an ownership of a memory segment required by at least one part of the application, and / or a security policy.

[0023] This ensures that, when operating the computing system, specific and detailed information and parameters of the first requirement information can be taken into account for unifying memory access.

[0024] In a fourth implementation form of the system according to the first aspect as such, the requirement information comprises second requirement information, wherein the second requirement information relates to executable binary code of at least one predefined code segment of the application, and wherein the operating system is further configured to control at least one of the first processing unit and the second processing unit and the shared memory based on the second requirement information in order to allocate the first memory segment to at least one part of the application.

[0025] This ensures that, when operating the computing system, specific and detailed information and parameters of the second requirement information can be taken into account for unifying memory access.

[0026] In a fifth implementation form of the system according to the first aspect as such, the second requirement information is executable binary code comprising information about an ABI used for compiling the predefined code segment of the application, and / or a memory model used for compiling the predefined code segment of the application, and / or a security policy for each memory segment accessible by the application.

[0027] This ensures that, when operating the computing system, specific and detailed information and parameters of the second requirement information can be taken into account for unifying memory access.

[0028] In a sixth implementation form of the system according to the first aspect as such, the requirement information comprises third requirement information, wherein the third requirement information relates to a connection between the shared memory and at least one of the first processing unit and the second processing unit, and wherein the operating system is further configured to control at least one of the first processing unit and the second processing unit and the shared memory based on the third requirement information in order to allocate the first memory segment to at least one part of the application.

[0029] This ensures that, when operating the computing system, information of the connection between the shared memory and at least one of the first processing unit and the second processing unit can be taken into account for unifying memory access.

[0030] In a seventh implementation form of the system according to the first aspect as such or according to the first aspect as any one of the preceding implementations of the first aspect, the third requirement information is created by the operating system and comprises information on cache coherency guarantees between at least one of the first memory segment and the second memory segment and at least one of the first processing unit and the second processing unit, and / or memory access latency between at least one of the first memory segment and the second memory segment and at least one of the first processing unit and the second processing unit, and / or existence and type of hardware protection mechanisms in the shared memory.

[0031] This ensures that specific and detailed information and parameters in the third requirement information can be considered when operating the computing system for unified memory access.

[0032] In an eighth implementation form of the system according to the first aspect as such or according to the first aspect as any one of the preceding implementations of the first aspect, the operating system is further configured to, if at least one of the first processing unit and the second processing unit, and / or at least one of the first memory segment and the second memory segment, and / or at least one part of the application does not comply with the requirements in the requirement information, adjust a configuration of at least one of the first processing unit and the second processing unit, and / or at least one of the first memory segment and the second memory segment, and / or at least one part of the application based on the requirement information, so as to allocate at least one of the first memory segment and the second memory segment to at least one part of the application.

[0033] This ensures that if a requirement in the requirement information is detected when performing memory access, a configuration of at least one of the first processing unit and the second processing unit, and / or at least one of the first memory segment and the second memory segment, and / or at least one part of the application can be adjusted based on the requirement information.

[0034] In a ninth implementation form of the system according to the first aspect as such or according to the first aspect as any one of the preceding implementations of the first aspect, the operating system is further configured to, if the first processing unit does not comply with the requirements in the requirement information, migrate at least one part of the application from operating by the first processing unit to operating by the second processing unit, and control the second processing unit based on the requirement information so as to allocate the first memory segment to at least one part of the application.

[0035] This ensures that if a requirement in the requirement information is detected when performing memory access, at least one part of the application can be migrated for unified memory access.

[0036] In a tenth implementation form of the system according to the first aspect as such or according to the first aspect as any one of the preceding implementation forms of the first aspect, the operating system is further configured to: if the executable binary code of the predefined part of the application does not comply with the requirements in the requirement information, exchange the executable binary code of the predefined part of the application with a pre-compiled executable binary code that complies with the requirements; and allocate the first memory segment to at least a part of the application based on the requirement information and the pre-compiled executable binary code.

[0037] This ensures that if a non-compliance with the requirements in the requirement information is detected when performing a memory access, the executable binary code of the predefined part of the application can be exchanged with a pre-compiled executable binary code for uniform memory access.

[0038] In an eleventh implementation form of the system according to the first aspect as such or according to the first aspect as any one of the preceding implementation forms of the first aspect, the operating system is further configured to: if the first memory segment does not comply with the requirements in the requirement information, control the at least one of the first processing unit and the second processing unit and the shared memory based on the requirement information, thereby allocating the second memory segment to at least a part of the application.

[0039] This ensures that if a non-compliance with the requirements in the requirement information is detected when performing a memory access, the at least one of the first processing unit and the second processing unit and the shared memory can be controlled, thereby allocating the second memory segment to at least a part of the application for uniform memory access.

[0040] In a twelfth implementation form of the system according to the first aspect as such or according to the first aspect as any one of the preceding implementation forms of the first aspect, the operating system is further configured to: if the first processing unit, the first memory segment and the executable binary code of the predefined part of the application do not comply with the requirements in the requirement information, allocate the first memory segment to at least a part of the application by means of software memory emulation based on the requirement information.

[0041] This ensures that if a non-compliance with the requirements in the requirement information is detected when performing a memory access, the first memory segment can be allocated to at least a part of the application by means of software memory emulation for uniform memory access.

[0042] In a thirteenth implementation form of the system according to the first aspect as such or according to the first aspect as any one of the preceding implementation forms of the first aspect, the at least two memory segments have different memory segment architectures.

[0043] This ensures that uniform memory access can be achieved, in particular in a heterogeneous computing system, more specifically in a system in which the at least two memory segments are of different architectures.

[0044] The second aspect of the present application provides a method for operating a computing system for uniform memory access. The computing system comprises: a first processing unit and a second processing unit; a shared memory comprising a first memory segment and a second memory segment; an operating system operated at least partly by the first processing unit; an application operated at least partly by the operating system; wherein the first processing unit and the second processing unit are connected to the shared memory, wherein the method comprises the following steps: based on requirement information included in the operating system and / or the application, the operating system controls at least one of the first processing unit and the second processing unit and the shared memory, so as to allocate the first memory segment to at least part of the application, wherein the requirement information comprises executable binary code, wherein the executable binary code comprises information about the type and / or state of the memory segment required by at least part of the application.

[0045] In a first implementation form of the method according to the second aspect, the first processing unit and the second processing unit have different processing unit architectures.

[0046] In a second implementation form of the method according to the second aspect, the requirement information further comprises first requirement information, wherein the first requirement information is related to the attributes of the executable binary code of at least part of the application, and the method further comprises: based on the first requirement information, the operating system controls at least one of the first processing unit and the second processing unit and the shared memory, so as to allocate the first memory segment to at least part of the application.

[0047] In a third implementation form of the method according to the second aspect, the first requirement information is executable binary code, comprising information about: an application binary interface (ABI) used for compiling at least part of the application, and / or a format used for compiling at least part of the application, and / or a persistence property, and / or an ownership of the memory segment required by at least part of the application, and / or a security policy.

[0048] In a fourth implementation form of the method according to the second aspect, the requirement information comprises second requirement information, wherein the second requirement information is related to the executable binary code of at least one predefined code segment of the application, and the method further comprises: based on the first requirement information, the operating system controls at least one of the first processing unit and the second processing unit and the shared memory, so as to allocate the first memory segment to at least part of the application.

[0049] In a fifth implementation form of the method according to the second aspect, the second requirement information is executable binary code, comprising information of: an ABI used for compiling the predefined code segment of the application, and / or a memory model related to compiling the predefined code segment of the application, and / or a security policy of each memory segment accessible by the application.

[0050] In a sixth implementation form of the method according to the second aspect, the requirement information comprises third requirement information, wherein the third requirement information is related to a connection between the shared memory and at least one of the first processing unit and the second processing unit, and the method further comprises: based on the third requirement information, the operating system controls at least one of the first processing unit and the second processing unit and the shared memory, so as to allocate the first memory segment to at least part of the application.

[0051] In a seventh implementation form of the method according to the second aspect, the third requirement information is created by the operating system, and comprises information of: a cache coherence guarantee between at least one of the first memory segment and the second memory segment and at least one of the first processing unit and the second processing unit, and / or a memory access latency between at least one of the first memory segment and the second memory segment and at least one of the first processing unit and the second processing unit, and / or existence and type of a hardware protection mechanism in the shared memory.

[0052] In an eighth implementation form of the method according to the second aspect, the method further comprises: if at least one of the first processing unit and the second processing unit, and / or at least one of the first memory segment and the second memory segment, and / or at least part of the application does not meet the requirement in the requirement information, based on the requirement information, the operating system adjusts a configuration of: at least one of the first processing unit and the second processing unit, and / or at least one of the first memory segment and the second memory segment, and / or at least part of the application, so as to allocate at least one of the first memory segment and the second memory segment to at least part of the application.

[0053] In a ninth implementation form of the method according to the second aspect, the method further comprises: if the first processing unit does not meet the requirement in the requirement information, the operating system migrates at least part of the application from operating by the first processing unit to operating by the second processing unit; and based on the requirement information, the operating system controls the second processing unit, so as to allocate the first memory segment to at least part of the application.

[0054] In a tenth implementation form of the method according to the second aspect, the method further comprises: if the executable binary code of the predefined part of the application does not meet the requirement in the requirement information, the operating system exchanges the executable binary code of the predefined part of the application with the pre-compiled executable binary code that meets the requirement information; and allocates the first memory segment to at least part of the application based on the requirement information and the pre-compiled executable binary code.

[0055] In an eleventh implementation form of the method according to the second aspect, the method further comprises: if the first memory segment does not meet the requirement in the requirement information, the operating system controls the at least one of the first processing unit and the second processing unit and the shared memory based on the requirement information, so as to allocate the second memory segment to at least part of the application.

[0056] In a twelfth implementation form of the method according to the second aspect, the method further comprises: if the first processing unit, the first memory segment and the executable binary code of the predefined part of the application do not meet the requirement in the requirement information, the operating system allocates the first memory segment to at least part of the application by means of software memory simulation based on the requirement information.

[0057] In a thirteenth implementation form of the method according to the second aspect, the at least two memory segments have different memory segment architectures.

[0058] The method of the second aspect and the implementation forms thereof achieves the same advantages as the system of the first aspect and the corresponding implementation forms thereof.

[0059] It should be noted that all devices, elements, units and means described in the present application can be implemented in software or hardware elements or any kind of combination thereof. All steps which are performed by the various entities described in the present application and the functionality described to be performed by the various entities are intended to refer to the respective entity is adapted to or configured to perform the respective steps and functionalities. Even if a specific functionality or step to be performed by external entities is not reflected in the description of a specific detailed element of that entity performing that specific step or functionality, it should be clear for the skilled person that these methods and functionalities can be implemented in respective software or hardware elements, or any kind of combination thereof. BRIEF DESCRIPTION OF DRAWINGS

[0060] The above aspects and implementation forms of the present application will be explained in the following description of specific embodiments in conjunction with the attached drawing, in which

[0061] Figure 1 A computing system according to an embodiment of the present application is shown;

[0062] Figure 2 A computing system according to an embodiment of the application is shown;

[0063] Figure 3 A more detailed computing system according to an embodiment of the application is shown;

[0064] Figure 4 A schematic diagram of the ELF format and the PE / COFF format is shown;

[0065] Figure 5 A schematic diagram of an OS process descriptor according to the application is shown;

[0066] Figure 6 A flowchart of an operating mode for unified memory access of an OS kernel is shown;

[0067] Figure 7 A schematic overview of a method according to an embodiment of the application is shown;

[0068] Figure 8 A computing system according to the prior art is shown. DETAILED DESCRIPTION

[0069] Figure 1 A computing system 100 according to an embodiment of the application is shown. The computing system 100 allows for unified memory access, including a first processing unit 101, a second processing unit 102, and a shared memory 103 including a first memory segment 104 and a second memory segment 105.

[0070] Hence, the processing units 101 and 102 can each be, for example, one of: a CPU, a CPU core, a GPU, a GPU core, a near-data processor, a CPU connected to a coherent interconnect, an accelerator interconnected with a CPU via a peripheral bus, a remote processing unit (e.g., a near-data processor, a CPU or a GPU) connected via an RDMA-capable interface, or a core (e.g., of an OS). The computing system 100 can include any number of processing units, as long as it includes at least a first processing unit 101 and a second processing unit 102, e.g., according to the definitions above.

[0071] Optionally, the first processing unit 101 and the second processing unit 102 can have different processing unit architectures. This can include that the first processing unit 101 is a first entity selected from the list above, and the second processing unit 102 is a different entity selected from the list above. This can also include that the first processing unit 101 and the second processing unit 102 are binary incompatible, e.g., because they operate according to different ISAs.

[0072] The shared memory 103 comprises a first memory segment 104 and a second memory segment 105. Each memory segment 104, 105 can be a classical main memory, e.g. a random access memory (RAM) or a storage class memory. Each memory segment 104, 105 can be volatile or non-volatile, and coherent or non-coherent. More specifically, the memory segments 104, 105 can be implemented on-chip, off-chip (e.g. through common DIMM modules), through a traditional coherent interconnect or inter-machine memory. More specifically, each link of the memory segments 104, 105 can be implemented using a cache coherent or non-coherent interconnect or a new technology such as CCIX, Gen-Z, OpenCAPI, Serial Memory Bus, etc. In particular, when forming the shared memory 103 (among other memory segments that can exist, including the first memory segment 104 and the second memory segment 105), the first memory segment 104 and the second memory segment 105 can optionally have different memory segment architectures, e.g. each chip providing one or more memory segments can be built according to different memory technologies and / or designs, and / or can comprise multiple segments with different memory technologies and / or designs. This can include that the first memory segment 104 is a first entity selected from the above list, and the second memory segment 105 is a second different entity selected from the above list. This can also include that the first memory segment 104 and the second memory segment 105 are binary incompatible, e.g. because they are operated according to different ISAs.

[0073] More specifically, the shared memory 103 can be used to enable multiple operating systems and / or multiple processing units and / or multiple applications to access the shared memory 103 simultaneously, preferably the same memory segment 104, 105 in the shared memory.

[0074] The computing system 100 further comprises an OS 106. The OS 106 can be a classical single-tasking or multi-tasking and / or single-user or multi-user OS, e.g. Linux, BSD, Windows or Apple OSX. The OS can also be a distributed, templated, embedded, real-time or library OS. The OS 106 can also comprise only a single kernel. The OS 106 can also comprise multiple kernels. The computing system 100 can operate using a single OS 106, but can also operate using multiple OSs 106 as long as there is at least one OS 106. In particular, the OS 106 can be binary incompatible with the first processing unit 101 and / or the second processing unit 102, i.e. operated according to different ISAs. When the computing system 100 comprises multiple OSs 106 operating on multiple processing units, the OSs 106 can be binary incompatible with each other.

[0075] Figure 1The OS 106 is shown in particular to operate on a plurality of processing units such as near data processors, CPUs, accelerators and remote units. The plurality of processing units further comprises the first processing unit 101 and the second processing unit 102. The OS 106 requires at least partly operating on the first processing unit 101. The second processing unit 102 can be controlled by the OS 106 to optimize the configuration of the computing system 100 to enable unified memory access.

[0076] Another configuration of the computing system 100 can also be included in this embodiment and will be described in the following according to Figure 2 Figure 2 In the configuration to be described according to

[0077] The computing system 100 further comprises an application 107. The application 107 is operated at least partly by the OS 106. This includes that the application can for example be a distributed application operated by a plurality of OSes, one of which is the OS 106. More specifically, the application 107 comprises at least one of the application parts "Code A", "Code B", "Code C" or "Code D" shown, to indicate that the application 107 can be operated by one OS on a plurality of processing units, or even by a plurality of kernels, OSes or run managers on a plurality of processing units. Figure 1 Figure 2 The application 107 obtains memory access, for example by trying to allocate a memory segment 104, 105 in the shared memory. Obtaining memory access can also involve operating on the first processing unit 101 and / or the second processing unit 102, the shared memory 103, one of its memory segments 104, 105 or the OS 106 to enable unified memory access.

[0078] To access the shared memory 103, the first processing unit 101 and the second processing unit 102 are connected to the shared memory 103, for example by a bus, more specifically via a bus supporting a load / store interface. The bus can provide different types of coherency for each different interconnect segment.

[0079] To enable unified memory access, the OS 106 is configured to control at least one of the first processing unit 101 and the second processing unit 102 and the shared memory 103 based on requirement information 108 included in the operating system 106 and / or the application 107 to allocate the first memory segment 104 to at least a part of the application 107. The requirement information 108 can also be maintained by software, for example by the OS 106 or the application 107.

[0080] ​​That is, the OS takes into account the requirement information 108 and performs a predefined action based on the requirement information 108 to control at least one of the first processing unit 101, the second processing unit 102 or the shared memory 103 to access the shared memory 103, more specifically to allocate the first memory segment 104 to at least one of the applications 107 requiring a memory to be allocated.

[0081] Further, the requirement information 108 also comprises executable binary code comprising information of the type and / or state of the memory segment 104, 105 required by at least one of the applications 107.

[0082] The OS 106 can load the executable binary code which also provides supplemental information for each program segment of the applications 107. The requirement information 108 can also be referred to as a memory contract. The memory contract can define the minimum requirements needed for correct memory access for each code (.text) subsegment of the applications 107. The requirement information 108, more specifically the executable binary code, can be created by a compiler which automatically generates the executable binary code transparently to the program developer, so that the program developer can modify the memory contract at compile time or at runtime, respectively, using additional language compilation directives or a new OS API.

[0083] The requirement information 108 can also comprise first requirement information, second requirement information and third requirement information, which will be described in more detail below with reference to Figure 3 the detailed description. The first requirement information can also be referred to as a data contract, the second requirement information can also be referred to as a participant contract and the third requirement information can also be referred to as a topology contract.

[0084] Figure 2 An exemplary configuration of a computing system 100 according to an embodiment of the present application is shown. Figure 2 The shown computing system 100 comprises Figure 1 all features of the computing system 100 described above, in particular, can operate using multiple OSs. The OSs can in particular belong to Figure 1 the types described above. The OS 106 is composed of Figure 2 multiple OSs in the computing system 100. The multiple OSs can in particular be binary incompatible with each other and / or with the first processing unit 101 and / or the second processing unit 102, i.e. operate according to different ISAs.

[0085] Figure 2The computing system 100 in the figure needs at least the operating system 106 to operate. However, due to the support of multiple operating systems, the computing system 100 can also be implemented in an environment where multiple operating systems run on multi-core, multi-processor or distributed systems. Each operating system can run on a respective processing unit. In particular, each operating system can run at least partially on a different processing unit, i.e. in a distributed manner. However, the operating system 106 needs to operate the computing system 100 and control each operating system in the computing system 100.

[0086] The multiple operating systems in the computing system 100 can be controlled by the operating system 106, e.g. to optimize the configuration of the computing system 100, to enable unified memory access, e.g. to at least partially migrate an application to a different operating system.

[0087] Figure 3 A more detailed computing system 300 according to an embodiment of the application is shown. The computing system 300 comprises all features and functions of the computing system 100 as described above according to Figure 1 and Figure 2 Thus, identical features are marked with identical reference signs. In the description according to Figure 3 , in particular the first, second and third requirement information, i.e. the data contract, the participant contract, the topology contract, as well as the concept of the memory contract will be described in more detail.

[0088] The memory contract can also be abstracted by the operating system, which provides an OS interface to the programmer. The memory contract can be metadata of an address space region (data, code, file, swap and / or combinations thereof). There are two kinds of memory contracts associated with an application 107: the data contract and the participant contract. The data contract can be associated with the executable code of an application, and the participant contract can be associated with the memory region accessed by said application. Furthermore, a topology contract can describe the characteristics of processing units to memory segments. Each operating system running on at least two processing units can use the memory contract to enforce at least the following memory region properties: format (in the sense of an ABI), consistency guarantees, cache capability guarantees, persistence, and user rights (memory protection). More examples will be provided below.

[0089] As shown in Figure 3 The requirement information 108 can optionally further comprise a first requirement information 301, which can also be referred to as a data contract.

[0090] The first requirement information 301 can relate to properties of an executable binary code of at least a part of the application 107. The operating system 106 is further configured to control at least one of the first processing unit 101 and the second processing unit 102 and the shared memory 103 based on the first requirement information 301, thereby allocating the first memory segment 104 to at least a part of the application 107.

[0091] The first requirement information (i.e. the data contract) represents the ABI and / or format used by the compiler when compiling the particular (initialized or uninitialized) data part of the application 107. Even if the heap and the stack are memory regions that are filled by the application 107 at runtime, their ABI and format can be defined at compile time, and thus the heap and the stack can be characterized by a data contract. For each memory mapped file, its data contract is inherited by the creating application, or set by the user. Persistence is another characteristic represented by the data contract. Since modern compilers support persistent memory, persistence can also be extracted at compile time. Finally, the data contract defines one or more ownership and security policies of the memory segment to grant capabilities to the memory segment and / or the process / handling unit.

[0092] In other words, the first requirement information 301 can be seen as an executable binary code, comprising information used when compiling the binary code (e.g. assumptions and rules), and more specifically, comprising information of: an ABI used to compile at least one part of the application 107, and / or a format used to compile at least one part of the application 107, and / or a persistence characteristic, and / or an ownership of a memory segment required by at least one part of the application 107, and / or a security policy.

[0093] In particular, the format specifies an alignment and / or a data structure field order, and / or an ABI, and / or an alignment, and / or a padding, and / or a structure field organization, and / or a persistence, and / or a caching capability.

[0094] Persistence is a property of a memory segment to preserve data after removal of power. A memory is non-persistent or volatile if the data stored in the memory is lost after removal of power. A memory is persistent if the data stored in the memory is not lost after removal of power. An example of a non-persistent memory is SDRAM or SRAM. An example of a persistent memory is NVDIMM or Flash. The persistence characteristic comprises information of the persistence of the shared memory 103 and / or of the memory segments 104, 105.

[0095] The ownership of a memory segment 104, 105 comprises information of which applications 107 or users can access the memory segment 104, 105.

[0096] As Figure 3 As further shown, the requirement information 108 can optionally also comprise a second requirement information 302, also referred to as a participant contract.

[0097] The second requirement information 302 can relate to the executable binary code of at least one predefined code segment of the application 107. The OS 106 can further be configured to control, based on the second requirement information 302, at least one of the first processing unit 101 and the second processing unit 102 and the shared memory 103, so as to allocate the first memory segment 104 to at least a part of the application 107.

[0098] The second requirement information 302 (i.e. the participant contract) can represent the ABI used by the compiler when compiling a specific code segment of the application 107. Furthermore, the participant contract states for each code segment for which memory model the code segment was compiled, e.g. consistency guarantees and cache capability requirements. Finally, the participant contract stores a set of capabilities (e.g. security policies) for each memory region it can access.

[0099] In other words, the second requirement information 302 can be seen as executable binary code comprising information on the ABI used to compile a predefined code segment of the application 107 and / or the memory model used to compile a predefined code segment of the application 107 and / or the security policies for each memory segment the application 107 can access.

[0100] Thus, consistency guarantees and cache capabilities can be seen as interrelated concepts.

[0101] Consistency is a memory property. When multiple processing units operate on the same memory segment, the type / level of consistency defines the way a modification made by the first processing unit 101 to the memory is propagated to the second processing unit 102. For example, "strong consistency" requires that every change made by the first processing unit 101 is immediately visible in the view of the memory segment of the second processing unit 102. Caching is a mechanism in memory hardware that provides consistency. Cache capability is the ability of the memory hardware to provide a certain consistency via caching.

[0102] In particular, the security policy can define the memory segments a single application 107 can read, write or execute. The security policy can further be defined as a set of properties that relate to the ability of the code to dynamically execute on a processing unit to access a predefined memory segment.

[0103] The above memory model can define the way a binary code can access a memory segment in a shared memory. This is because the same memory segment can have different cache capabilities, access latencies, protection mechanisms and persistence properties for different processing units.

[0104] In another implementation example, in the computing system 100, the work of the operating system can be distributed (in different quantities) between the operating system 106, the runtime manager and the virtual machine monitor.

[0105] AsFigure 3 Further, the requirement information 108 can optionally also comprise third requirement information 303, also referred to as topology contract.

[0106] The third requirement information can relate to a connection between the shared memory 103 and at least one of the first processing unit 101 and the second processing unit 102. The operating system 106 is further configured to control the at least one of the first processing unit 101 and the second processing unit 102 and the shared memory 103 based on the third requirement information 303, thereby allocating the first memory segment 104 to at least one of the applications 107.

[0107] In one specific implementation of the computing system 300, the OS 106 can be built from multiple kernels, each running on a different processing unit. The information about the topology of the computing system and the data contract of each shared memory segment is shared between these kernels.

[0108] Since there are multiple memory segments 104 and 105 in the computing system 100 and the virtual memory region can be relocated between these segments, the third requirement information, i.e. the topology contract, is needed. The third requirement information describes the connection between a physical memory segment and each specific processing unit. The topology contract can also describe the cache coherency guarantees that exist between a memory segment and a processing unit. In addition, other information can be associated with the topology contract, such as information about the memory access latency, whether the memory is persistent, the existence and type of hardware protection mechanisms between memory links. In particular, the third requirement information 303 can be created by the operating system 106, more specifically based on the hardware topology / geometry of the computing system 300, i.e. the way the hardware components are connected in the computing system 300.

[0109] In other words, the third requirement information 303 can comprise information about the cache coherency guarantees between at least one of the first memory segment 104 and the second memory segment 105 and at least one of the first processing unit 101 and the second processing unit 102, and / or the memory access latency between at least one of the first memory segment 104 and the second memory segment 105 and at least one of the first processing unit 101 and the second processing unit 102, and / or the existence and type of hardware protection mechanisms in the shared memory 103.

[0110] The cache coherency guarantees can be seen as a set of different processing units that require coherent access to a memory segment when a cache coherency mechanism is inserted between the processing unit and the memory segment. The cache coherency mechanism can provide different types of coherency, such as sequential consistency or total store order (TSO). The cache coherency mechanism can not exist at all, or just snoop memory bus operations.

[0111] The memory access latency can be seen as the time needed to perform a memory access as instructed by the processing unit. Indeed, a single access can take different amounts of time based on the physical distance of the memory segment from the processing unit and whether the specific data is cached or not.

[0112] The hardware protection mechanism can be memory paging and / or memory segmentation (segmented memory).

[0113] In another implementation example, the memory contract of the above type remains transparent to the user of the computing system 300. The memory contract is handled by the compiler at runtime or by the OS without programmer intervention. The memory contract is generated by the compiler and the linker in a first instance, including the contract description for the generation of code and data (sub)segments. In addition to the ABI contract, the compiler can add a description of this memory model. These descriptions are generated internally or by a syntax expression such as C++11 atomics. The compiler and the linker can embody additional information in the generated binary code. The compiler and the linker can split a.text segment, which is usually one whole, into multiple subsegments, which can be assigned to different participant contracts. In a specific implementation example of the compiler and the linker, a compiler directive can also be added to the programming language to mark memory segments that are to be shared and thus accessible by variable base pointers from different devices.

[0114] The requirement information 108, i.e. the memory contract, is used by the OS 106 to uniformly access the shared memory segments 104, 105, in particular by enforcing the plurality of properties: the OS 106 enforces all memory contracts by checking whether all code segments in the applications 107 connected to the same memory segment 104, 105, e.g. running on the first processing unit 101 and / or on other processing units, comply with each data contract, participant contract and topology contract of the connection to the memory segment. If the code segments in the applications 107 do not have a valid data contract, participant contract or topology contract, i.e. if the memory access to the shared memory 103 does not comply with any of the first requirement information 301, the second requirement information 302 or the third requirement information 303, the OS 106 can perform several actions. Although these actions are described in the context of the computing system 100 according to Figure 3 but they can also be applied to the computing system 100 as described according to Figure 1 or Figure 2 That is, the actions can also be performed based on the requirement information 108 only, i.e. based on the memory contract only, i.e. without the data contract, participant contract or topology contract, in the absence of the first requirement information 301, the second requirement information 302 and the third requirement information 303.

[0115] That is, performing the action can comprise that the operating system 106 is further configured to, if at least one of the first processing unit 101 and the second processing unit 102, and / or at least one of the first memory segment 104 and the second memory segment 105, and / or at least one part of the application 107 does not comply with the requirements in the requirements information 108, then adjust the configuration of at least one of the first processing unit 101 and the second processing unit 102, and / or at least one of the first memory segment 104 and the second memory segment 105, and / or at least one part of the application 107 based on the requirements information 108, thereby allocating at least one of the first memory segment 104 and the second memory segment 105 to at least one part of the application 107.

[0116] Adjusting the configuration of at least one of the above entities can in particular comprise that if the application 107 requires allocation of a memory segment that does not guarantee to meet the requirements information 108 (e.g. the first, second or third requirements information, or the compiled and linked properties of the currently executed code (sub-) segment), then the OS can perform the following actions:

[0117] - cancel execution of the application 107. It can also disable RW operations on the required memory segment, thereby causing a fault.

[0118] - migrate the application 107 to another processing unit that complies with the requirements information (e.g. the compiled and linked properties). Note that this can depend on the availability of executable binaries that can be run on the other processing unit. This can be achieved by generating the executable binary required for the other processing unit at compile time.

[0119] - exchange the code (sub-) segment of the application 107 with another version that requires a weaker set of guarantees. Note that this depends on the availability of the executable binary, which can be generated at runtime if not already available.

[0120] - migrate the memory segment 104 that the application 107 wants to operate on to another memory segment 105 that complies with the requirements in the requirements information 108 (e.g. from the perspective of the processing unit that wants to operate on the memory segment 104, 105).

[0121] - comply with the requirements in the requirements information 108 by using software emulation (e.g. via the form of virtual distributed shared memory).

[0122] To achieve the above-mentioned actions, in other words, the operating system 106 can also be configured to: if the executable binary code of the predefined part in the application 107 does not meet the requirement in the requirement information 108, exchange the executable binary code of the predefined part in the application 107 with a pre-compiled executable binary code that meets the requirement information; and allocate the first memory segment 104 to at least part of the application 107 based on the requirement information 108 and the pre-compiled executable binary code.

[0123] Therefore, when there is a data consistency mismatch or an ABI mismatch, the OS 106 can switch between different binary code versions (compiled based on semantically equivalent source code, or the same source code) in the application 107, thereby meeting different consistency contracts and ABI participant contracts (different binary code versions can be generated at compile time, or in time, i.e., during application runtime, or in user space).

[0124] Additionally or alternatively, the operating system 100 can also be configured to: if the first processing unit 101 does not meet the requirement in the requirement information 108, migrate at least part of the application 107 from being operated by the first processing unit 101 to being operated by the second processing unit 102; and control the second processing unit 102 to allocate the first memory segment 104 to at least part of the application 107 based on the requirement information 108.

[0125] Additionally or alternatively, the operating system 106 can also be configured to: if the first memory segment 104 does not meet the requirement in the requirement information 108, control at least one of the first processing unit 101 and the second processing unit 102 and the shared memory 103 to allocate the second memory segment 105 to at least part of the application 107 based on the requirement information 108.

[0126] Therefore, when the data consistency is violated, the OS 106 can decide to provide data consistency via a distributed shared memory, or move the memory segment of the code block to another memory segment or processing unit that provides an effective topology contract.

[0127] Additionally or alternatively, the operating system 106 can also be configured to: if the first processing unit 101, the first memory segment 104, and the executable binary code of the predefined part in the application 107 do not meet the requirement in the requirement information 108, allocate the first memory segment 104 to at least part of the application 107 by means of software memory emulation based on the requirement information 108.

[0128] Furthermore, for ABI inconsistencies, the runtime manager can finally determine the pseudo code (e.g., OpenCL) to a specific ABI. The new API then provides a way for programmers to manipulate the contract at runtime, enabling user-defined behavior and fine-tuning.

[0129] The requirements information 108 used by the computing system 100 includes executable binary code that includes information of the type and / or state of at least a portion of the memory segments required by the application 107. Such executable binary code can also be referred to as an enhanced executable binary file, an enhanced executable binary format, or an enhanced executable binary code.

[0130] Figure 4 A schematic diagram 400 is shown of an executable and linking format (ELF) 401 and a portable executable (PE) / common object file format (COFF) 402 as examples of executable binary files. The present invention is applicable to both formats. In both cases, there are a header section 403, a code section 404, a data section 405, and a debug / symbol section 406. Furthermore, the present invention can generally be applied to any possible file format, not limited to the given examples. These examples represent the most commonly used file formats.

[0131] To provide a suitable format of executable binary files, such as the ELF format 401 and the PE / COFF format 402, the compiler used (e.g., GCC, LLVM / clang, MSVC) should support multiple memory models, ISAs, and ABIs. To generate the ELF format 401 or the PE / COFF format 402, the traditional compilation process needs to remain unchanged, only the backend involved in the compilation and the linker are modified. The modified backend generates code (in the code section 404) for multiple versions of.text that support different memory models, ISAs, and ABIs. The number of versions is not limited. All different versions can be included in the enhanced executable binary file and should be interchangeable within the same address range of the same address space. The modified linker can put all these different code versions in the same executable binary file while marking each section and providing backward compatibility with the original format 407. The modified linker can also create a new executable binary program section 408, which can be referred to as a "contract". In this section, all compiler assumptions used during compilation that cannot be extracted from the debug section are included.

[0132] To implement the present application, a conventional OS binary loader can be modified to load additional executable binary sections added to an enhanced executable binary file. These sections augment the conventional OS data structures that describe the address space.

[0133] The OS binary loader can detect additional metadata emitted by the compiler at binary load / execution time (e.g., when the execve() system call is executed in the Linux kernel). Accordingly, the OS binary loader sets up the address space for the load process. In this process, the OS 106 can check that the memory allocated to the application 107 in the computing system 100 meets the requirements expressed in the metadata included in the executable binary file. Further enhancements to the address space OS abstraction are made to include additional optional code (sub) sections and metadata information.

[0134] Figure 5 An illustrative diagram 500 of a process descriptor 501 usable by an OS is shown. Figure 5 An illustrative diagram of a process descriptor 501 in a conventional OS (e.g., Linux, BSD, Windows, or Apple OSX) is shown. In these OSs, the address space of an application is described by a linked data structure of virtual memory region descriptors 502. Each descriptor is associated with a logical portion of the program address space, such as a.text section, a.data section, or a HEAP section. The process descriptor 501 can also include binary format descriptors 503. According to the present application, associated with each virtual memory region descriptor 502 is one or more "memory contracts," such as a data descriptor 504 or a participant descriptor 505. The data descriptor 504 (or data contract) is associated with a non-code region of the program and describes the compile-time used compile options and conventions. The participant descriptor 505 (or participant contract) is associated with a code region of the program and describes the minimum memory model required for consistent memory access for each sub-section of code. Multiple participant contracts can be associated with multiple versions of the same code facing the address space. At load time of the computing system 100, the OS can map each code of the non-code section while guaranteeing the requirements set forth in the contracts.

[0135] Figure 6 An illustrative flow diagram 600 of the manner of operation for uniform memory access by an OS kernel is shown. The flow diagram 600 describes, in particular, how the OS kernel can use the additional metadata (i.e., requirements information) according to the present application to access heterogeneous memory regions during process runtime.

[0136] Figure 7 An illustrative overview of a method 700 according to an embodiment of the present application is shown. The method 700 corresponds to Figure 1the system 100, respectively, for operating a computing system 100 for uniform memory access.

[0137] The method 700 comprises the step of controlling (701), by the operating system 106, at least one of the first processing unit 101 and the second processing unit 102 and the shared memory 103, based on requirement information included in the operating system 106 and / or the application 107, thereby allocating the first memory segment 104 to at least a part of the application 107, wherein the requirement information comprises executable binary code, wherein the executable binary code comprises information of a type and / or a state of a memory segment required by at least a part of the application 107.

[0138] Figure 8 A computing system 800 according to the prior art is shown. In particular, the content shown in this patent can be applied to the computer architecture shown in this figure. In addition to a dedicated CPU, a plurality of other processing units (e.g. NDPs, accelerators or RDMA) can access a common memory area simultaneously, as shown in Figure 8 The content shown in this patent can be used to unify such heterogeneous memory access.

[0139] The application has been described in connection with various embodiments and implementations as examples and implementations. However, other variations can be understood and implemented by those skilled in the art from a study of the drawings, the disclosure, and the independent claims. In the claims and specification, the word "comprising" does not exclude other elements or steps, and the indefinite article "a" or "an" does not exclude a plurality. A single processor or other unit can fulfill the functions of several entities recited in the claims. The mere fact that certain measures are recited in mutually different dependent claims does not indicate that a combination of these measures cannot be used to advantage.

Claims

1. A computing system for unified memory access, the computing system comprising: Comprising: a first processing unit and a second processing unit; the first processing unit and the second processing unit have different processing unit architectures; the first processing unit comprises a CPU; a shared memory comprising a first memory segment and a second memory segment; an operating system operated at least in part by the first processing unit; an application operated at least in part by the operating system; wherein the first processing unit and the second processing unit are connected to the shared memory, and the operating system is configured to control at least one of the first processing unit and the second processing unit and the shared memory based on requirement information included in the operating system and / or requirement information included in the application, so as to allocate the first memory segment to at least part of the application, and the requirement information comprises executable binary code, wherein the executable binary code comprises information of a type of a memory segment required by at least part of the application and / or information of a type state of a memory segment required by at least part of the application.

2. The computing system of claim 1, wherein, the requirement information further comprises first requirement information, wherein the first requirement information is related to a property of executable binary code of at least part of the application, and the operating system is further configured to control at least one of the first processing unit and the second processing unit and the shared memory based on the first requirement information, so as to allocate the first memory segment to at least part of the application.

3. The computing system of claim 2, wherein, the first requirement information is executable binary code comprising at least one of the following information: an application binary interface (ABI) used for compiling at least part of the application, a format used for compiling at least part of the application, a persistence characteristic, an ownership of a memory segment required by at least part of the application, and a security policy.

4. The computing system of any of claims 1-3, wherein, the requirement information comprises second requirement information, wherein the second requirement information is related to executable binary code of at least one predefined code segment of the application, and the operating system is further configured to control at least one of the first processing unit and the second processing unit and the shared memory based on the second requirement information, so as to allocate the first memory segment to at least part of the application.

5. The computing system of claim 4, wherein, the second requirement information is executable binary code comprising at least one of the following information: an ABI used for compiling the predefined code segment of the application, a memory model used for compiling the predefined code segment of the application, and a security policy of each memory segment accessible by the application.

6. The computing system of any one of claims 1-3, wherein, the requirement information comprises third requirement information, wherein the third requirement information is related to a connection between the shared memory and at least one of the first processing unit and the second processing unit, and the operating system is further configured to control at least one of the first processing unit and the second processing unit and the shared memory based on the third requirement information, so as to allocate the first memory segment to at least part of the application.

7. The computing system of claim 6, wherein, The third requirement information is created by the operating system and includes at least one of the following: cache coherency guarantee between at least one of the first memory segment and the second memory segment and at least one of the first processing unit and the second processing unit, memory access latency between at least one of the first memory segment and the second memory segment and at least one of the first processing unit and the second processing unit, and existence and type of hardware protection mechanism in the shared memory.

8. The computing system of any of claims 1-3, wherein, The operating system is further configured to: if at least one of the first processing unit and the second processing unit, and / or at least one of the first memory segment and the second memory segment, and / or at least a part of the application does not meet the requirement in the requirement information, adjust the configuration of at least one of the first processing unit and the second processing unit, and / or at least one of the first memory segment and the second memory segment, and / or at least a part of the application based on the requirement information, so as to allocate at least one of the first memory segment and the second memory segment to at least a part of the application.

9. The computing system of any one of claims 1-3, wherein, The operating system is further configured to: if the first processing unit does not meet the requirement in the requirement information, migrate at least a part of the application from operating by the first processing unit to operating by the second processing unit; and control the second processing unit based on the requirement information, so as to allocate the first memory segment to at least a part of the application. The computing system comprises:

10. A method for operating a computing system for unified memory access, characterized in that, a first processing unit and a second processing unit; the first processing unit and the second processing unit have different processing unit architectures; the first processing unit comprises a CPU; a shared memory comprising at least two memory segments; the at least two memory segments comprise a first memory segment and a second memory segment; an operating system operated at least partially by the first processing unit; an application operated at least partially by the operating system; wherein the first processing unit and the second processing unit are connected to the shared memory, wherein the method comprises the following steps: the operating system controls at least one of the first processing unit and the second processing unit and the shared memory based on requirement information included in the operating system and / or the application, so as to allocate the first memory segment to at least a part of the application, wherein the requirement information comprises executable binary code, wherein the executable binary code comprises information of type of memory segment required by at least a part of the application and / or information of state of memory segment required by at least a part of the application. The requirement information further comprises first requirement information, wherein the first requirement information is related to attributes of executable binary code of at least a part of the application, and the operating system is further configured to control at least one of the first processing unit and the second processing unit and the shared memory based on the first requirement information, so as to allocate the first memory segment to at least a part of the application.

11. The method of claim 10, wherein, ​ 12. The method of claim 11, wherein, The first requirement information is executable binary code, including at least one of the following: an application binary interface (ABI) used for compiling at least a part of the application, a format used for compiling at least a part of the application, a persistence characteristic, an ownership of a memory segment required by at least a part of the application, and a security policy.

13. The method according to any one of claims 10-12, characterized in that, The requirement information includes second requirement information, wherein the second requirement information is related to executable binary code of at least one predefined code segment of the application, and the operating system is further configured to control at least one of the first processing unit and the second processing unit and the shared memory based on the second requirement information, so as to allocate the first memory segment to at least a part of the application.

14. The method of claim 13, wherein, The second requirement information is executable binary code, including at least one of the following: an ABI used for compiling the predefined code segment of the application, a memory model used for compiling the predefined code segment of the application, and a security policy of each memory segment accessible by the application.

15. The method of any one of claims 10-12, wherein, The requirement information includes third requirement information, wherein the third requirement information is related to a connection between the shared memory and at least one of the first processing unit and the second processing unit, and the operating system is further configured to control at least one of the first processing unit and the second processing unit and the shared memory based on the third requirement information, so as to allocate the first memory segment to at least a part of the application.

16. The method of claim 15, wherein, The third requirement information is created by the operating system, and includes at least one of the following: a cache coherence guarantee between at least one of the first memory segment and the second memory segment and at least one of the first processing unit and the second processing unit, a memory access latency between at least one of the first memory segment and the second memory segment and at least one of the first processing unit and the second processing unit, and existence and type of a hardware protection mechanism in the shared memory.

17. The method of any one of claims 10-12, wherein, The method further includes: if at least one of the first processing unit and the second processing unit, and / or at least one of the first memory segment and the second memory segment, and / or at least a part of the application does not meet a requirement in the requirement information, adjusting a configuration of at least one of the first processing unit and the second processing unit, and / or at least one of the first memory segment and the second memory segment, and / or at least a part of the application based on the requirement information, so as to allocate at least one of the first memory segment and the second memory segment to at least a part of the application.

18. The method of any one of claims 10-12, wherein, The method further includes: if the first processing unit does not meet a requirement in the requirement information, migrating at least a part of the application from operating by the first processing unit to operating by the second processing unit; and controlling the second processing unit based on the requirement information, so as to allocate the first memory segment to at least a part of the application.

19. The method of any one of claims 10-12, wherein, The method further comprises: if the executable binary code of the predefined part of the application does not meet the requirement in the requirement information, exchanging the executable binary code of the predefined part of the application with pre-compiled executable binary code meeting the requirement information; and allocating the first memory segment to at least part of the application based on the requirement information and the pre-compiled executable binary code.

20. The method of any one of claims 10-12, wherein, The method further comprises: if the first memory segment does not meet the requirement in the requirement information, controlling the at least one of the first processing unit and the second processing unit and the shared memory based on the requirement information, so as to allocate the second memory segment to at least part of the application.

21. The method of any one of claims 10-12, wherein, The method further comprises: if the first processing unit, the first memory segment and the executable binary code of the predefined part of the application do not meet the requirement in the requirement information, allocating the first memory segment to at least part of the application in a manner of software memory simulation based on the requirement information.

22. The method of any one of claims 10-12, wherein, The at least two memory segments have different memory segment architectures.

23. A computer-readable storage medium, characterized in that, The computer program product comprises instructions which, when executed on a computer, cause the computer to perform the method of any one of claims 10-22.

Images