JP6932755B2 - Operating system and memory allocation method - Google Patents

Description

The present invention relates to an operating system running in a multi-core environment in which processor cores are interconnected, and a memory allocation method.

In recent years, systems such as embedded products have become complicated, and an increasing number of systems have adopted a multi-core processor having a plurality of processor cores in order to realize multiple functions. In such a multi-core environment, it is important to share memory between each processor core to efficiently use resources and to avoid memory conflicts to increase the processing speed.

By the way, such a system often has a plurality of different types of memories, and the access speed of each memory is also different. Therefore, it is important to appropriately allocate which memory is used according to the content of the process.

However, the developer of the application program does not always know the type of memory, so it is desirable for the operating system to perform the appropriate memory allocation. For example, if the application program requires a memory with a high access speed, the operating system may select the memory with a high access speed and execute the memory allocation from the memory.

As described in Patent Document 1, in a system having a memory (primary cache) unique to each processor core, the memory having the fastest access speed for a certain processor core is the memory unique to that processor core. Is. Therefore, the memory with the fastest access speed changes depending on the processor core at the time of execution.

Japanese Unexamined Patent Publication No. 2012-53817

As mentioned above, if the fastest access memory changes depending on the processor core at runtime, the operating system dynamically selects the fastest access memory to perform the memory allocation. If this is possible, it is possible to improve the efficiency of memory resources and the processing speed.

Therefore, it is an object of the present invention to provide an operating system and a memory allocation method capable of dynamically selecting a memory having a high access speed and executing memory allocation when a program is executed.

The present invention has been made to solve the above-mentioned problems, and is characterized by the following.

The present invention is an operating system that implements a memory acquisition API that can be called from an application program and is executed in a multi-core environment in which a plurality of processor cores each having local memory are interconnected, and preset internal data. A memory area creation unit that creates a plurality of memory areas according to the above, and a memory allocation unit that refers to the heap ID specified as an argument of the memory acquisition API and executes memory allocation from the memory area associated with the heap ID. And, the memory area includes a core memory area related to the local memory of the plurality of processor cores and a memory area related to a memory having an access speed slower than the local memory. In the memory area, a tree structure is created in which the core memory area is the lowest layer and the memory area related to the memory having a slow access speed is arranged higher than the core memory area, and the memory allocation unit is created. Is characterized in that, when the memory allocation from the memory area specified by the heap ID fails, the memory allocation is executed from the memory area higher than the memory area.

The present invention is as described above. When a tree structure is created in the memory area and memory allocation from the memory area specified by the heap ID fails, memory allocation is executed from a memory area higher than the memory area. I am trying to do it. Therefore, for example, even when the memory resource having a high access speed is exhausted, the memory allocation can be executed from the next candidate memory area. Therefore, it is possible to search for a memory area having as fast an access speed as possible and execute memory allocation.

It is a figure which shows the structure of the processor and the memory which concerns on embodiment of this invention. It is a figure which shows the structure of the operating system which concerns on memory management. It is a figure which shows the flow concerning a compilation process. It is a figure explaining the format for describing the definition of memory in a configuration file. It is a figure explaining the format for describing the definition of a memory area in a configuration file. It is a figure explaining the format for describing the definition of a heap ID in a configuration file. It is a figure which shows the description example of the configuration file. It is a figure which shows the tree structure of the memory area. It is a figure explaining the specification of the memory acquisition API. It is a main flow diagram of a memory allocation process. It is a flow diagram of a global memory allocation process. It is a flow diagram of a cluster memory allocation process. It is a flow diagram of a core memory allocation process. It is a flow diagram of a real memory allocation process.

An embodiment of the present invention will be described with reference to the drawings.

The operating system 10 according to the present embodiment is a program executed in a multi-core environment in which a plurality of processor cores are interconnected as shown in FIG. 1, for example. The operating system 10 manages hardware resources and provides various services that abstract the hardware resources to the application program 40. For example, it implements a memory acquisition API that can be called from the application program 40, thereby providing a service that allows the application program 40 to safely use the memory resource. When this memory acquisition API is called from the application program 40, the operating system 10 executes memory allocation from the physical memory and returns a pointer indicating the start address of the allocated memory to the application program 40. The application program 40 can execute various processes using the memory by referring to this pointer.

The multi-core processor according to the present embodiment includes a plurality of processor cores. In this embodiment, as shown in FIG. 1, four processor cores, a first processor core 30a, a second processor core 30b, a third processor core 30c, and a fourth processor core 30d. It has. In addition, each of these four processor cores has its own local memory (primary cache, etc.). That is, there are a local memory 31a of the first processor core, a local memory 31b of the second processor core, a local memory 31c of the third processor core, and a local memory 31d of the fourth processor core.

In the present embodiment, a multi-core processor having four processor cores is described as an example, but the present invention is not limited to this, and the number of processor cores may be three or less or five or more. Further, a multi-core environment may be configured by using a plurality of chips having a plurality of processor cores.

Further, the execution environment according to the present embodiment includes a shared memory such as an SDRAM in addition to the memory unique to the processor core. These shared memories are allocated to cluster memory that is supposed to be used by a specific cluster and global memory 34 that can be accessed from all processor cores. The cluster is, for example, a processor core divided into several groups in order to improve the management efficiency of a multi-core environment. In the present embodiment, the first processor core 30a and the second processor core 30b form a first cluster 32a, and the third processor core 30c and the fourth processor core 30d form a second cluster 32b. Consists of. Cluster memory is allocated to each of these clusters. That is, the first cluster memory 33a and the second cluster memory 33b.

Although not particularly described in this embodiment, the cluster structure may be hierarchized. That is, the clusters may be managed in a tree structure by setting higher-level clusters that are parents of a plurality of clusters.

In the present embodiment, as shown in FIG. 1, the memory having the fastest access speed for a specific processor core is the memory specific to that processor core (for example, the memory having the fastest access speed for the first processor core 30a). Is the local memory 31a of the first processor core). The memory having the next fastest access speed (or priority) is the memory of the cluster to which it belongs (for example, for the first processor core 30a, it is the first cluster memory 33a). Further, the next fastest (or preferred) memory is the memory of the cluster's parent (eg, global memory 34 for the first processor core 30a).

Therefore, the environment is such that the memory having a high access speed and the memory to be preferentially allocated change depending on which processor core the application program 40 is executed in. For example, when the application program 40 is executed on the first processor core 30a, the memory having the fastest access speed is the local memory 31a of the first processor core. On the other hand, when the application program 40 is executed on the second processor core 30b, the memory having the fastest access speed is the local memory 31b of the second processor core.

In order to execute appropriate memory allocation in such an environment, the operating system 10 according to the present embodiment includes a memory area creation unit 12 and a memory allocation unit 14, as shown in FIG.

The memory area creation unit 12 is for reading the internal data 43 described later at the time of initializing the system and creating a plurality of memory areas 20 according to the contents of the internal data 43. The memory area 20 is a unit for the operating system 10 to manage memory resources. The memory area creation unit 12 divides the memory into addresses and sizes to create a plurality of memory areas 20, and also creates a tree structure in these memory areas 20 (see FIG. 8). This tree structure will be described in detail later.

When the memory acquisition API is called, the memory allocation unit 14 refers to the heap ID specified as an argument of the memory acquisition API, and executes memory allocation from the memory area 20 associated with the heap ID. be. The heap ID is defined in the configuration file 41 described later and can be rewritten by the user. This heap ID will be described in detail later.

In the present embodiment, the memory allocation unit 14 includes a microkernel 16 and a heap manager 15.

The microkernel 16 is a program that controls the execution of a program in each processor core, and is executed one by one in each processor core. Therefore, when there are four processor cores as in the present embodiment, the four microkernels 16 corresponding to the respective processor cores are executed. When the application program 40 calls the memory acquisition API, the instruction is notified to the microkernel 16 that controls the processor core executing the application program 40. Upon receiving the instruction, the microkernel 16 identifies the memory area 20 to execute the memory allocation based on the argument (heap ID) of the memory acquisition API, and requests the heap manager 15 that manages the memory area 20 to perform the memory. Perform the assignment.

The heap manager 15 is a program that controls each memory area 20, and is executed one by one for each memory area 20. For example, when seven memory areas 20 exist as shown in FIG. 8, seven heap managers 15 corresponding to the respective memory areas 20 are executed. As described above, the heap manager 15 is called by the microkernel 16 when the memory acquisition API is called, and executes memory allocation from the memory area 20 managed by itself. Specifically, when the microkernel 16 requests memory allocation, the heap manager 15 secures a memory of the size specified by the microkernel 16 and notifies the microkernel 16 of the address, and the memory is used. Manage so that it will not be used for memory allocation again until it is explicitly released.

As shown in FIG. 8, the memory area 20 managed by the heap manager 15 can be roughly classified into three types. That is, the core memory area, the cluster memory area, and the global memory area 23.

The core memory area is a memory area 20 related to the local memory of a plurality of processor cores, and these memory areas 20 are created to be managed by the operating system 10. This core memory area is created in the same number as multiple processor cores. In the present embodiment, the first core memory area 21a corresponding to the local memory 31a of the first processor core, the second core memory area 21b corresponding to the local memory 31b of the second processor core, and the third A third core memory area 21c corresponding to the local memory 31c of the processor core and a fourth core memory area 21d corresponding to the local memory 31d of the fourth processor core are created.

The cluster memory area is a memory area 20 associated with one or more core memory areas, and is created for managing these memory areas 20 by the operating system 10. In this embodiment, the same number of cluster memory areas as the clusters are created. That is, a first cluster memory area 22a corresponding to the first cluster memory 33a and a second cluster memory area 22b corresponding to the second cluster memory 33b are created.

The global memory area 23 is a memory area 20 associated with one or more cluster memory areas, and is created for managing these memory areas 20 by the operating system 10. In this embodiment, only one global memory area 23 is created. However, a plurality of global memory areas 23 may be provided.

The core memory area, the cluster memory area, and the global memory area 23 form a hierarchical structure as shown in FIG. That is, a tree structure is formed in which the core memory area is the lowest layer, the cluster memory area is the intermediate layer, and the global memory area 23 is the uppermost layer. In the example shown in FIG. 8, the cluster memory area has one layer, but the cluster memory area may form a plurality of layers.

The address, size, tree structure, and other attributes of these memory areas 20 are determined by the description of the configuration file 41 as shown in FIG. 7. Therefore, the setting of the memory area 20 can be changed by rewriting the description of the configuration file 41. For example, the setting can be changed so that the memory area 20 is set according to the configuration of the physical memory, the number of processor cores, and the like, and can be used for controlling the operating system 10.

Further, in this configuration file 41, the relationship between the memory area 20 and the heap ID can be freely described and set. This allows the application program 40 to access the desired memory area 20 using the heap ID.

As shown in FIG. 3, this configuration file 41 is read and used by the information generating means 42. The information generating means 42 is a configuration tool that can be executed independently (for example, a file in an executable format that can be executed on a computer), reads the contents described in the configuration file 41, and is a header for the application program 40. Generate file 44 and internal data 43 for operating system 10.

Of these, the internal data 43 is used by the memory area creation unit 12 described above to read the internal data 43 at the time of system initialization to create the memory area 20.

On the other hand, the header file 44 is used when compiling the source code 45 of the application program 40. Specifically, the header file 44 is used when the compiler 46 compiles the source code 45 of the application program 40, thereby generating the object file 47. Since the heap ID is defined in the header file 44, the application program 40 can use the heap ID to call the memory acquisition API by referring to the header file 44.

(Description example of configuration file 41)
Next, a description example of the configuration file 41 will be described. Note that FIG. 7 is a specific description example of the configuration file 41. In the configuration file 41 shown in FIG. 7, three definitions of DEF_MEM (definition of memory), DEF_MEMOBJ (definition of memory area 20), and DEF_HEAP (definition of heap ID) can be described.

FIG. 4 is a format for describing the memory definition (DEF_MEM) in the configuration file 41. By using this format, the memory space can be divided by the address and the size, and a memory ID (a unique character string used in the configuration file 41) can be assigned to the divided memory. Specifically, the memory ID specified by memory is assigned to the memory of the size specified by memsz from the address described in startaddr.

For example, in the example shown in FIG. 7 (1), a memory ID of MEM_SDRAM1 is assigned to the memory of 0x8000000 (that is, the memory in the range of 0xc0000000 to 0xc7ffffff) with 0xc0000000 as the start address.

FIG. 5 shows the definition of the memory area 20 (DEF) in the configuration file 41.
_MEMOBJ) is a format for describing. By using this format, the memory area 20 can be created by specifying the name, position, attribute, parent-child relationship, and relationship with the processor core.

In the format shown in FIG. 5, "name of memory area 20 (unique character string used in the configuration file 41)" is specified for memobjid.

The "attribute of the memory area 20" is specified for the memory. The attribute that can be specified is one of "MOA_GLOBAL" meaning the global memory area 23, "MOA_CLUSTER" meaning the cluster memory area, and "MOA_CORE" meaning the core memory area.

For the ownercoreid, "the number of the processor core that manages this memory area 20" is specified. Specifically, when the memory area 20 is a core memory area, it is specified which processor core the local memory is associated with. For example, if it is a core memory area (first core memory area 21a shown in FIG. 8) associated with the local memory 31a of the first processor core, “1” is specified. When the memory area 20 is not the core memory area, the number of the processor core on which the heap manager 15 that manages the memory area 20 is executed is specified.

"The name of the memory area 20 that is the parent of this memory area 20" is specified for the part id. Specifically, in the case of a core memory area, the name of the parent cluster memory area is specified. In the case of a cluster memory area, the name of the parent cluster memory area or the global memory area 23 is specified. In the case of the global memory area 23, the default value "MEMOBJ_ROOT" indicating that there is no parent is specified.

A "list of memory IDs belonging to this memory area 20" is specified for memoryist. That is, a list of memory IDs defined by the description method described with reference to FIG. 4 is specified.

For example, in the example shown in FIG. 7 (2), MEM_SDRAM1 (memory in the range of 0xc0000000 to 0xc7ffffff) and MEM_SDRAM2 (0xcc0000000).
A global memory area 23 is created with the name "MEMOBJ_GLOBAL1" for the memory in the range of ~ 0xcffffffff).

Further, in the example shown in FIG. 7 (3), MEM_CLUSTER1 (0x8120000)
For memory in the range of ~ 0x8127efff), "MEMOBJ_CLUSTER1
A cluster memory area is created with the name. The parent memory area 20 of this cluster memory area is "MEMOBJ_GLOBAL1".

Further, in the example shown in FIG. 7 (4), a core memory area is created with the name "MEMOBJ_CORE1" for MEM_CORE1 (memory in the range of 0x81000000 to 0x81007fff). The core memory area uses the local memory of the processor core of the number "1", and the parent memory area 20 of this core memory area is "MEMOBJ_CLUSTER1".
By defining the memory area 20 in this way, a tree structure as shown in FIG. 8 is created.

FIG. 6 is a format for describing the definition of the heap ID (DEF_HEAP) in the configuration file 41. By using this format, the relationship between the heap ID and the memory area 20 can be described.

In the format shown in FIG. 6, "heap ID (unique character string that can be used in the application program 40)" is specified for heapid.
A "predetermined virtual attribute" or a "name of the memory area 20 associated with the heap ID" is specified in the memory.

The "predetermined virtual attributes" that can be specified for memobjid include "MEMOBJ_GLOBAL" indicating that this heap ID is a virtual global ID, and "MEMOBJ_CLUSTER" indicating that this heap ID is a virtual cluster ID. Any of "MEMOBJ_CORE" indicating that this heap ID is a virtual core ID can be specified.

For example, in the example shown in FIG. 7 (5), a virtual global ID is created with a heap ID of "HEAP_GLOBAL". The virtual global ID is a heap ID for referring to the global memory area 23. When the application program 40 calls the memory acquisition API using the virtual global ID, the operating system 10 searches for the available global memory area 23 and executes memory allocation from the global memory area 23.

Further, in the example shown in FIG. 7 (6), a virtual cluster ID is created with a heap ID of "HEAP_CLUSTER". The virtual cluster ID is a heap ID for dynamically allocating a cluster memory area. When the application program 40 calls the memory acquisition API using the virtual cluster ID, the operating system 10 searches for a available cluster memory area and executes memory allocation from this cluster memory area.

Further, in the example shown in FIG. 7 (7), a virtual core ID is created with a heap ID of "HEAP_CORE". The virtual core ID is a heap ID for dynamically allocating a core memory area. When the application program 40 calls the memory acquisition API using the virtual core ID, the operating system 10 searches for an available core memory area and executes memory allocation from this core memory area.

Further, as the "name of the memory area 20 associated with the heap ID" that can be specified in the memory, the name of the memory area 20 defined by the description method described with reference to FIG. 5 can be specified. When the name of the memory area 20 is directly specified in this way, the heap ID and the memory area 20 are directly associated with each other. When the application program 40 calls the memory acquisition API using such a heap ID, the operating system 10 allocates the memory directly from the designated memory area 20. Such a heap ID is called a real memory ID.

For example, in the example shown in FIG. 7 (8), a real memory ID is created with a heap ID of "HEAP_CLUSTER1". This real memory ID is directly associated with the memory area 20 defined by the name "MEMOBJ_CLUSTER1".

Further, in the example shown in FIG. 7 (9), a real memory ID is created with a heap ID of "HEAP_CORE1". This real memory ID is directly associated with the memory area 20 defined by the name "MEMOBJ_CORE4".

In askpart, it is specified whether or not to refer to the parent memory area 20 when the memory allocation from the specified memory area 20 fails. When "true" is specified, memory allocation is performed by recursively referring to the memory area 20 of the parent of the tree structure as shown in FIG. For example, when the memory allocation from the first core memory area 21a fails, the memory allocation from the first cluster memory area 22a is tried. If the memory allocation from the first cluster memory area 22a also fails, the memory allocation from the global memory area 23 is attempted. On the other hand, when "false" is specified, the memory allocation from the parent memory area 20 is not performed even if the memory allocation from the designated memory area 20 fails.

(API for memory acquisition)
Next, the specifications of the memory acquisition API will be described. The operating system 10 according to the present embodiment includes, for example, a memory acquisition API as shown in FIG. 9, and the memory acquisition API can be called from the application program 40. "Heapid", "size", and "addr" can be specified as arguments to this memory acquisition API.

A "heap ID" is specified for heapid. The operating system 10 attempts to allocate memory from the memory area 20 specified by the heap ID specified here. For the heap ID, any one of the virtual global ID, the virtual cluster ID, the virtual core ID, and the real memory ID as described above can be specified. When the application program 40 uses the heap ID, the header file 44 output by the information generating means 42 is referred to. In this header file 44, the heap ID is defined in a form that can be used by the application program 40. The heap ID defined in the header file 44 is not limited to the one defined in the configuration file 41, and the information generating means 42 may automatically add the heap ID. For example, the information generation means 42 may automatically output to the header file 44 even if at least one of the virtual global ID, the virtual cluster ID, and the virtual core ID is not defined in the configuration file 41. ..
For size, specify the "size of memory you want to acquire".

For addr, specify "a pointer to an area that returns the start address of the acquired memory". When the memory acquisition is successful, the application program 40 can obtain the start address of the acquired memory by referring to the contents of this pointer.

The return value of this API is an error code. Specifically, if the memory acquisition is successful, "EOK (constant)" is returned, if size or addr is invalid, "EPAR (constant)" is returned, and if the heap ID is invalid, it is returned. "ENOEXS (constant)" is returned, and if memory acquisition fails due to memory exhaustion or the like, "ENOMEM (constant)" is returned.

(Memory allocation process)
Next, the processing of the operating system 10 when the above-mentioned memory acquisition API is called will be described. FIG. 10 is a main flow diagram of the memory allocation process.

First, in step S100 shown in FIG. 10, the application program 40 executes a memory acquisition API call, and the microkernel 16 receives a memory acquisition request resulting from this API call. At this time, the microkernel 16 that receives the memory acquisition request is the microkernel 16 that is executed in the processor core in which the application program 40 is executed. The microkernel 16 acquires the heap ID specified by the memory acquisition API, refers to the internal data 43 based on the heap ID, and checks the attributes of the heap ID. Then, the process proceeds to step S101.

In step S101, it is checked whether the heap ID is a virtual global ID (that is, whether it is a heap ID defined by giving the MEMOBJ_GLOBAL attribute in the configuration file 41). If it is a virtual global ID, the process proceeds to step S102 to execute the global memory allocation process (see FIG. 11). On the other hand, if it is not a virtual global ID, the process proceeds to step S103.

In step S103, it is checked whether the heap ID is a virtual cluster ID (that is, whether it is a heap ID defined by giving the MEMOBJ_CLUSTER attribute in the configuration file 41). If it is a virtual cluster ID, the process proceeds to step S104, and the cluster memory allocation process (see FIG. 12) is executed. On the other hand, if it is not a virtual cluster ID, the process proceeds to step S105.

In step S105, it is checked whether the heap ID is a virtual core ID (that is, whether it is a heap ID defined by giving the MEMOBJ_CORE attribute in the configuration file 41). If it is a virtual core ID, the process proceeds to step S106 to execute the core memory allocation process (see FIG. 13). On the other hand, if it is not a virtual core ID, since this heap ID is a real memory ID, the process proceeds to step S107 to execute the real memory allocation process (see FIG. 14).

(Global memory allocation processing)
The global memory allocation process will be described with reference to FIG.
First, in step S200 shown in FIG. 11, the microkernel 16 acquires the number of the processor core that calls the memory acquisition API (in this embodiment, the number of the processor core in which the microkernel 16 is executed). Then, the process proceeds to step S201.

In step S201, the microkernel 16 refers to the tree structure of the memory area 20 based on the processor core number acquired in step S200, and acquires the core memory area associated with the number. For example, when the processor core number is "1", the core memory area (core memory area defined by the description in (4) of FIG. 7) in which "1" is specified for the ownercore in the configuration file 41 is acquired. Then, the process proceeds to step S202.

In step S202, it is checked whether the acquired memory area 20 has the “MOA_GLOBAL” attribute, that is, the global memory area 23. If it is the global memory area 23, the memory area 20 is selected as the memory allocation target, and the process proceeds to step S204. On the other hand, if it is not the global memory area 23, the process proceeds to step S203.

When the process proceeds to step S203, the memory area 20 of the parent of the acquired memory area 20 is acquired. That is, in the tree structure as shown in FIG. 8, the memory area 20 of the parent of the currently acquired memory area 20 is acquired. Then, the process returns to step S203, and it is checked whether or not the newly acquired memory area 20 is the global memory area 23. Then, in the case of the global memory area 23, the memory area 20 is selected as the target of memory allocation, and the process proceeds to step S204. On the other hand, if it is not the global memory area 23, the process proceeds to step S203 and the same processing as described above is performed. In this way, the parent memory area 20 is recursively acquired until the global memory area 23 is found.

In step S204, the microkernel 16 calls the heap manager 15 that manages the memory area 20 selected as the target of memory allocation, and requests the heap manager 15 to allocate memory. Then, the process proceeds to step S205.

In step S205, it is checked whether the memory allocation by the heap manager 15 is successful. If the memory allocation is successful, the process proceeds to step S206. On the other hand, if the memory allocation fails due to the exhaustion of memory resources, the process proceeds to step S207.

When the process proceeds to step S206, the memory pointer of the acquired memory is returned to the application program 40. By using this memory pointer, the application program 40 can safely use the memory. And the process ends.

On the other hand, when the process proceeds to step S207, it is checked whether to acquire the parent memory area 20. When the parent memory area 20 does not exist, or when the heap ID specified in the argument of the memory acquisition API does not refer to the parent memory area 20 (askparent is defined in the definition of the heap ID in the configuration file 41). In the case of false), the process proceeds to step S209. In other cases, referring to the tree structure as shown in FIG. 8, the parent memory area 20 of the memory area 20 that failed to allocate the memory is selected as the target of the memory allocation, and the process proceeds to step S208.
If the process proceeds to step S209, the error code is returned to the application program 40. And the process ends.

On the other hand, when the process proceeds to step S208, the heap manager 15 that manages the memory area 20 of the parent selected as the target of memory allocation is called, and the heap manager 15 is requested to allocate memory. Then, the process proceeds to step S205 described above, and the procedure already described is repeated. At this time, if the memory allocation fails even in the parent memory area 20, the memory allocation from the parent memory area 20 is recursively tried.

As described above, in the global memory allocation process, the memory area 20 (core memory area) related to the local memory of the processor core in which the application program 40 is executed is specified, and the memory area 20 associated with the memory area 20 is specified. The memory allocation is executed from the global memory area 23 found by recursively tracing.

(Cluster memory allocation processing)
The cluster memory allocation process will be described with reference to FIG.
First, in step S300 shown in FIG. 12, the microkernel 16 acquires the number of the processor core that calls the memory acquisition API (in this embodiment, the number of the processor core in which the microkernel 16 is executed). Then, the process proceeds to step S301.

In step S301, the microkernel 16 refers to the tree structure of the memory area 20 based on the processor core number acquired in step S300, and acquires the core memory area associated with the number. Then, the process proceeds to step S303.

In step S303, the memory area 20 of the parent of the acquired core memory area is selected as the memory allocation target. The parent memory area 20 of this core memory area is a cluster memory area having the “MOA_CLUSTER” attribute. Then, the process proceeds to step S304.

Since the processing in steps S304 to S309 is the same as the processing in steps S204 to S209 of the global memory allocation processing described above, the description thereof will be omitted.

In this way, in the cluster memory allocation process, the core memory area related to the local memory of the processor core in which the application program 40 is executed is specified, and the memory allocation is executed from the cluster memory area associated with the core memory area. Let me.

(Core memory allocation process)
The core memory allocation process will be described with reference to FIG.
First, in step S400 shown in FIG. 13, the microkernel 16 acquires the number of the processor core that calls the memory acquisition API (in this embodiment, the number of the processor core in which the microkernel 16 is executed). Then, the process proceeds to step S401.

In step S401, the microkernel 16 refers to the tree structure of the memory area 20 based on the processor core number acquired in step S400, and selects the core memory area 20 associated with the number as the memory allocation target. .. Then, the process proceeds to step S402.

In step S402, the microkernel 16 calls the heap manager 15 that manages the core memory area selected as the memory allocation target, and the heap manager 15 executes the memory allocation. Then, the process proceeds to step S403.

Since the processing in steps S403 to S407 is the same as the processing in steps S205 to S209 of the global memory allocation processing described above, the description thereof will be omitted.

As described above, in the cluster memory allocation process, the memory allocation is executed from the core memory area related to the local memory of the processor core in which the application program 40 is executed.

(Real memory allocation process)
The real memory allocation process will be described with reference to FIG.
First, in step S500 shown in FIG. 14, the microkernel 16 allocates the memory area 20 associated with the heap ID based on the heap ID (real memory ID) specified by the argument of the memory acquisition API. Select as a target. For example, when the heap ID "HEAP_CORE4" defined in FIG. 7 (9) is specified by the argument of the memory acquisition API, the memory area 20 named "MEMOBJ_CORE4" associated with this heap ID is stored in the memory. Select as the target of allocation. Then, the process proceeds to step S501.

In step S501, the microkernel 16 calls the heap manager 15 that manages the memory area 20 selected as the memory allocation target, and requests the heap manager 15 to allocate the memory. Then, the process proceeds to step S502.

Since the processing in steps S502 to S506 is the same as the processing in steps S205 to S209 of the global memory allocation processing described above, the description thereof will be omitted.

As described above, in the real memory allocation process, the memory allocation is executed from the memory area 20 associated with the designated real memory ID.

(summary)
As described above, according to the present embodiment, when the real memory ID is specified and the memory acquisition API is called, the memory allocation is executed from the memory area 20 associated with the specified real memory ID. I have to. Therefore, when it is desired to execute the memory allocation from the specific memory specified by the application program 40, the memory acquisition API may be called by specifying the actual memory ID.

Further, when the virtual core ID is specified and the memory acquisition API is called, the memory allocation is executed from the core memory area related to the local memory of the processor core in which the application program 40 that called the memory acquisition API is executed. I am trying to do it. Therefore, if you want the operating system 10 to dynamically select a memory with a high access speed (memory unique to the processor core) and execute memory allocation, you can call the memory acquisition API by specifying the virtual core ID. ..

Further, when the virtual cluster ID is specified and the memory acquisition API is called, the core memory area related to the local memory of the processor core in which the application program 40 that called the memory acquisition API is executed is specified, and the core is concerned. The memory allocation is executed from the cluster memory area associated with the memory area. Therefore, for example, when the processor core is divided into several groups (clusters) and the memory area 20 is allocated to the cluster in order to improve the management efficiency of the multi-core environment, the memory area 20 for this cluster is used as the cluster memory area. By defining it, the operating system 10 can dynamically determine when the program is executed and execute the memory allocation from the cluster memory area.

Further, when the virtual global ID is specified and the memory acquisition API is called, the memory area 20 related to the local memory of the processor core in which the application program 40 that called the memory acquisition API is executed is specified, and the memory is concerned. The memory allocation is executed from the global memory area 23 found by recursively tracing the memory area 20 associated with the area 20. Therefore, for example, by setting the memory that can be accessed from all the processor cores as the global memory area 23, the operating system 10 can dynamically determine when the program is executed and execute the memory allocation from the global memory area 23. ..

Moreover, since a plurality of memory allocation methods as described above are realized by the same memory acquisition API, it is possible to switch the memory allocation method simply by changing the definition of the heap ID without changing the application program 40. can. For example, if the definition of the heap ID is changed by rewriting the configuration file 41 and the heap ID assigned to the virtual core ID is assigned to the real memory ID, the heap ID is used to acquire the memory API. The memory allocation method can be switched without changing the application program 40 that was calling. When the virtual core ID is changed to the real memory ID, before changing the heap ID definition, the memory allocation is executed from the memory area 20 peculiar to the processor core at the time of program execution, and the heap ID definition is changed. After that, the memory allocation from the specific memory area 20 specified by the heap ID is executed.

Further, a tree structure is created in the memory area 20, and when the memory allocation from the memory area 20 specified by the heap ID fails, the memory allocation is executed from the upper memory area 20 of the memory area 20. .. Therefore, for example, even when the memory resource having a high access speed is exhausted, the memory allocation can be executed from the next candidate memory area 20. Therefore, the memory area 20 having the fastest access speed can be searched and the memory allocation can be executed.

Further, information that reads the configuration file 41 that describes the relationship between the heap ID and the memory area 20 and the configuration file 41 to generate the header file 44 for the application program 40 and the internal data 43 for the operating system 10. The generation means 42 and the like are provided. According to such a configuration, the definition of the memory area 20 and the definition of the heap ID can be changed without changing the application program 40 or the operating system 10 simply by rewriting the configuration file 41 and executing the information generation means 42. can do. For example, even when porting a program to a hardware environment having different physical memory or processor core, the application program 40 or the operating system 10 can be changed simply by rewriting the configuration file 41 and executing the information generation means 42. It is possible to realize an appropriate memory allocation.

10 Operating system 12 Memory area creation unit 14 Memory allocation unit 15 Heap manager 16 Microkernel 20 Memory area 21a First core memory area 21b Second core memory area 21c Third core memory area 21d Fourth core memory area 22a 1st cluster memory area 22b 2nd cluster memory area 23 Global memory area 30a 1st processor core 30b 2nd processor core 30c 3rd processor core 30d 4th processor core 31a Local memory of 1st processor core 31b Local memory of the second processor core 31c Local memory of the third processor core 31d Local memory of the fourth processor core 32a First cluster 32b Second cluster 33a First cluster memory 33b Second cluster memory 34 Global memory 40 Application program 41 Configuration file 42 Information generation means 43 Internal data 44 Header file 45 Application program source code 46 Compiler 47 Object file

Claims (4)

An operating system that implements a memory acquisition API that can be called from an application program and is executed in a multi-core environment in which multiple processor cores, each with local memory, are interconnected.
A memory area creation unit that creates multiple memory areas according to preset internal data,
A memory allocation unit that refers to the heap ID specified as an argument of the memory acquisition API and executes memory allocation from the memory area associated with the heap ID.
With
The memory area includes a core memory area related to the local memory of the plurality of processor cores and a memory area related to a memory having an access speed slower than the local memory.
The memory area and the heap ID are defined in a user-rewritable file.
The memory area creation unit creates a tree structure in which the core memory area is the lowest layer and the memory area related to the memory having a slow access speed is arranged higher than the core memory area in the memory area. death,
The memory allocation unit
An operating system characterized in that when a memory allocation from a memory area specified by the heap ID fails, a memory allocation is executed from a memory area higher than the memory area. The memory area related to the memory having a slow access speed includes a cluster memory area associated with one or more core memory areas and a global memory area associated with one or more cluster memory areas.
The memory area creation unit is characterized in that the cluster memory area is arranged higher than the core memory area and the global memory area is arranged higher than the cluster memory area. The operating system according to claim 1. It is a memory allocation method for causing a computer to execute memory allocation when an API for memory acquisition is called from an application program in a multi-core environment in which multiple processor cores each having local memory are connected to each other.
A step in which the computer creates a plurality of memory areas according to preset internal data,
A step in which the computer refers to the heap ID specified as an argument of the memory acquisition API and executes memory allocation from the memory area associated with the heap ID.
With
The memory area includes a core memory area related to the local memory of the plurality of processor cores and a memory area related to a memory having an access speed slower than the local memory.
The memory area and the heap ID are defined in a user-rewritable file.
The computer creates a tree structure in which the memory area of the memory area, the core memory area is the lowest layer, and the memory area related to the memory having a slow access speed is arranged higher than the core memory area.
A memory allocation method, wherein the computer executes memory allocation from a memory area higher than the memory area when the memory allocation from the memory area specified by the heap ID fails. The memory area related to the memory having a slow access speed includes a cluster memory area associated with one or more core memory areas and a global memory area associated with one or more cluster memory areas.
The computer is characterized by creating a tree structure in which the cluster memory area is arranged higher than the core memory area and the global memory area is arranged higher than the cluster memory area. Item 3. The memory allocation method according to item 3.

Images