WO2014190486A1 - 支持多核架构下资源隔离的方法及系统 - Google Patents

支持多核架构下资源隔离的方法及系统 Download PDF

Info

Publication number
WO2014190486A1
WO2014190486A1 PCT/CN2013/076329 CN2013076329W WO2014190486A1 WO 2014190486 A1 WO2014190486 A1 WO 2014190486A1 CN 2013076329 W CN2013076329 W CN 2013076329W WO 2014190486 A1 WO2014190486 A1 WO 2014190486A1
Authority
WO
WIPO (PCT)
Prior art keywords
core
processing
operating system
processing core
runtime
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Ceased
Application number
PCT/CN2013/076329
Other languages
English (en)
French (fr)
Inventor
雷晓松
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Huawei Technologies Co Ltd
Original Assignee
Huawei Technologies Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Huawei Technologies Co Ltd filed Critical Huawei Technologies Co Ltd
Priority to CN201380000917.5A priority Critical patent/CN103608792B/zh
Priority to JP2015559405A priority patent/JP6089349B2/ja
Priority to PCT/CN2013/076329 priority patent/WO2014190486A1/zh
Priority to EP13885510.1A priority patent/EP2851807B1/en
Publication of WO2014190486A1 publication Critical patent/WO2014190486A1/zh
Priority to US14/573,428 priority patent/US9411646B2/en
Anticipated expiration legal-status Critical
Ceased legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
    • G06F9/5005—Allocation of resources, e.g. of the central processing unit [CPU] to service a request
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/52—Program synchronisation; Mutual exclusion, e.g. by means of semaphores
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/4401—Bootstrapping
    • G06F9/4405—Initialisation of multiprocessor systems
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/4401—Bootstrapping
    • G06F9/4406—Loading of operating system

Definitions

  • the present invention relates to computer technologies, and in particular, to a method and system for supporting resource isolation in a multi-core architecture.
  • BACKGROUND OF THE INVENTION A cloud storage system based on a large-scale unified resource pool, with data storage and management as the core, supports unified deployment of multiple services, efficiently uses disks, can reduce investment losses on demand, and effectively utilize resources and reduce integration through reasonable scheduling. Energy consumption.
  • the prior art adopts a multi-core ARM processor with a small number of hard disks, such as an ARM server based on Reduced Instruction Set Computing (RISC), which can achieve low power consumption, high integration, and low comprehensive cost of the ARM processor.
  • RISC Reduced Instruction Set Computing
  • Embodiments of the present invention provide a method and system for supporting resource isolation in a multi-core architecture, so that a fault domain of a multi-core processor is maintained on a single hard disk.
  • an embodiment of the present invention provides a system for supporting resource isolation in a multi-core architecture, where the system includes: a processor, where the processor includes multiple processing cores, and the multiple processing cores include a startup core And at least one boot-time slave core; the memory space, the memory space includes a shared memory segment, and a memory segment of each processing core; the shared memory segment stores running information, and a runtime entry address of each processing core;
  • the operation information includes a correspondence between each processing core and each operating system, a size of each memory segment, and a starting address.
  • the runtime entry address of each processing core is used to indicate that each processing core needs to be operated.
  • Kernel image of the operating system The storage address of the file in the respective memory segment; wherein, the processor stores the kernel image files of the operating system that each processing core needs to run into the memory segment of each processing core, and processes each core
  • the runtime entry addresses are respectively written into the shared memory segment; the processing cores to be started respectively acquire respective runtime entry addresses, and run the kernel image files of the operating systems stored in the respective memory segments.
  • each processing core of the processor determines, in each processing core, a runtime main core according to a preset election algorithm; the runtime main core is configured to perform Arbitration control of input/output I/O resources.
  • the runtime puts data that requires an I/O operation from the core into the shared memory segment, and the I/ The O-operation related memory address notifies the runtime main core to cause the runtime main core to call its own local physical drive to perform the I/O operation on the external device.
  • the runtime invokes its own local physical drive from the core to perform an I/O operation on the external device.
  • the boot loader is provided in the booting core;
  • the processor stores the kernel image files of the operating systems that need to be run by the processing cores in the memory segments of the processing cores respectively, and includes: the operations that the boot loader needs to run according to the operation information.
  • the system's kernel image files are stored in the memory segments of each processing core.
  • the boot loader is provided in the booting core;
  • the processor stores the kernel image files of the operating system that each processing core needs to run into the memory segment of each processing core, including: the boot loader processes at least one of the processors according to the operation information.
  • a kernel image file of the operating system to be run is stored in the memory segment of the core, and a kernel image file of the operating system is run; and the processing core running the operating system runs the processor according to the operation information.
  • the kernel image files of the operating system corresponding to the remaining processing cores of the operating system are respectively stored in the memory segments of the remaining processing cores.
  • the processing core group consisting of at least two processing cores runs a kernel image file of the same operating system, and all processing cores constituting the processing core group share the same segment Memory segment; or, each processing core runs a kernel image file of an operating system that is different from each other.
  • the embodiment of the present invention provides a method for supporting resource isolation in a multi-core architecture, and is applicable to a system for supporting resource isolation in a multi-core architecture, including a processor and a memory space, where: the processor includes multiple processing cores.
  • the plurality of processing cores include a boot-time main core and at least one boot-time slave core;
  • the memory space includes a shared memory segment, and a memory segment of each processing core; and the shared memory segment stores running information.
  • the operation information includes a correspondence between each processing core and each operating system, a size of each memory segment, and a starting address; a runtime entry address of each processing core, a storage address of the kernel image file of the operating system that is required to be executed by each processing core in a respective memory segment;
  • the method for supporting resource isolation in a multi-core architecture includes:
  • the processor stores the kernel image files of the operating systems that need to be run by the processing cores into the memory segments of the processing cores, and writes the runtime entry addresses of the processing cores into the shared memory segments respectively;
  • the processing cores to be started respectively acquire their respective runtime entry addresses and run the kernel image files of the operating systems stored in the respective memory sections.
  • each processing core of the processor determines, in each processing core, a runtime main core according to a preset election algorithm; and the running main core is configured to perform Arbitration control of input/output I/O resources.
  • the runtime puts data that requires an I/O operation from the core into the shared memory segment, and the I/ The O-operation related memory address notifies the runtime main core to cause the runtime main core to call its own local physical drive to perform the I/O operation on the external device.
  • the runtime invokes its own local physical drive from the core to perform the I/O operation on the external device.
  • the startup loader is disposed in the main core during startup;
  • the processor stores the kernel image files of the operating system that each processing core needs to run into the memory segment of each processing core, including:
  • the boot loader stores the kernel image files of the operating systems that need to be run by the processing cores in the memory segments of the processing cores according to the operation information.
  • the processor stores the kernel image files of the operating system that each processing core needs to run into the memory segments of each processing core, including:
  • the boot loader stores, according to the operation information, a kernel image file of an operating system that needs to be run in a memory segment of at least one processing core of the processor, and runs a kernel image file of the operating system;
  • the processing core of the operating system stores the kernel image files of the operating system corresponding to the remaining processing cores of the processor that are required to run the operating system in the memory segments of the remaining processing cores.
  • any one of the first to fifth possible implementation manners of the second aspect in a sixth possible implementation, the processing core group formed by the at least two processing cores performs the same operation a kernel image file of the system, and all processing cores constituting the processing core group share the same segment of the memory segment; or each processing core runs a kernel image file of an operating system different from each other.
  • the method and system for supporting resource isolation in a multi-core architecture provided by the embodiments of the present invention, and operating on different processing cores of a multi-core processor by means of isolation of inter-core operating systems, isolation of memory segments, and isolation of I/O resources
  • the system can operate independently without affecting each other. Therefore, the multi-core processor has the advantages of high integration and low comprehensive cost, and the fault domain of the multi-core processor is maintained on a single hard disk, which has high reliability.
  • FIG. 1 is a schematic structural diagram of a system for supporting resource isolation in a multi-core architecture according to Embodiment 1 of the present invention
  • FIG. 1b is a schematic diagram of a topology structure of a cloud storage system using a system for supporting resource isolation in a multi-core architecture according to Embodiment 1 of the present invention
  • FIG. 2 is a shared memory segment in a system for supporting resource isolation in a multi-core architecture, as shown in FIG. Schematic diagram of the local structure
  • FIG. 3 is a schematic structural diagram of a system for supporting resource isolation in a multi-core architecture according to Embodiment 2 of the present invention.
  • FIG. 4a is a schematic diagram of an implementation of verifying access to an external device during operation of a system for supporting resource isolation in a multi-core architecture according to Embodiment 2 of the present invention
  • FIG. 4b is a schematic diagram of another implementation of verifying access to an external device during operation of a system for supporting resource isolation in a multi-core architecture according to Embodiment 2 of the present invention
  • FIG. 5 is a flow chart of a method for supporting resource isolation in a multi-core architecture according to Embodiment 3 of the present invention. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS
  • FIG. 1 is a schematic structural diagram of a system for supporting resource isolation in a multi-core architecture according to Embodiment 1 of the present invention.
  • the system 10 supporting resource isolation under the multi-core architecture shown in FIG. 10 is applicable to a cloud storage system based on a large-scale unified resource pool.
  • Figure lb is a schematic diagram showing the topology of a cloud storage system using a system for supporting resource isolation in a multi-core architecture according to the first embodiment of the present invention.
  • the cloud storage system 100 includes: a switch 102, at least one system 10 supporting resource isolation under a multi-core architecture, and at least one application server 101.
  • the application server 101 is connected to the switch 102, and the system 10 supporting resource isolation under the multi-core architecture is connected to the switch 102.
  • the system 10 for supporting resource isolation in a multi-core architecture of the present embodiment includes: a processor 1 1 and a memory space 12, where:
  • the processor 11 comprising a plurality of processing cores: a booting master core 1 11 and at least one booting slave core 1 12;
  • the memory space 12 includes a shared memory segment 123, a memory segment 121 of the primary core 11 1 at startup, and a memory segment 122 from the core 112 at startup; the shared memory segment 123 stores operational information, and the runtime of each processing core
  • the operation address includes a correspondence between each processing core and each operating system, a size of each memory segment, and a start address.
  • the runtime entry address of each processing core is used to indicate each processing core.
  • the storage address of the kernel image file of the operating system that needs to be run in the respective memory segment;
  • the processor 11 will process the kernel image file of the operating system that each processing core needs to run. Stored in the memory segment of each processing core, and writes the runtime entry address of each processing core into the shared memory segment 123; the processing cores to be started respectively acquire respective runtime entry addresses, and are stored and stored in their respective The kernel image file of the operating system in the memory segment.
  • the processor 11 is a multi-core processor including a plurality of processing cores, for example, an ARM or an Intel ATOM processor may be used, but the invention is not limited thereto.
  • the processor 11 includes a plurality of processing cores, and FIG. 1a exemplarily shows a case where the processor 11 includes a boot-time master core 111 and a boot-time slave core 112.
  • the processor 11 may include one or more boot-time slave cores. , will not repeat them here.
  • the main core 111 at startup refers to the processing core of the boot loader 1111 that is predetermined by the hardware, and the main core 111 can trigger other processing cores to start and run when booting; when booting from the core 112, the processor 11 is booting.
  • FIG. 1a shows the corresponding relationship between the main core 111 at startup and the operating core 1 and the operating system 2 from the core 112 at startup, wherein the operating system 1 and the operating system 2 can be LINUX, Windows, Solaris DOS, OS/2. , UNIX, XENIX Netware, or different versions of the same operating system, and, operating system 1 and operating system 2 can be identical operating systems, different versions of the same operating system, or different types of operating systems, but The invention is not limited thereto.
  • FIG. 2 is a schematic diagram showing a partial structure of a shared memory segment in a system for supporting resource isolation in a multi-core architecture, as shown in FIG.
  • the shared memory segment 123 stores the operation information 123a, the runtime entry address 123b of the slave core 112 at startup, and the runtime entry address 123c of the host core 111 at startup; wherein, the operation information 123a Recording the planning information of the memory segment, including at least: the correspondence between each processing core and each operating system, the size of each memory segment, and the starting address, that is, the following information: (1)
  • the main core 111 is running at startup.
  • Operating system 1 the size and starting address of the memory segment 121 allocated for the main core 111 at startup; (2) operating system 2 from the core 112 at startup, and the size and memory of the memory segment 122 from the core 112 at startup Start address; (3) Size and start address of shared memory segment 123.
  • the memory segments are independent of each other and are isolated from each other, so that mutually independent memory segments are allocated for different operating systems. If the start address of each memory segment is not specified, the default is from address 0, or from the previous memory area. The end address of the segment begins as the starting address of the memory segment.
  • the operation information address 1231 is the storage address of the operation information 123a in the shared memory segment 123.
  • Each processing core needs to follow the convention of the operation information address 1231, and the operation information is queried by the operation information address 1231, optionally, in each processing core.
  • the operating system's kernel image file indicates the operation information address of each processing core, and the running information can be dynamically modified and adjusted during system operation.
  • the runtime entry address pointer 1232 from the core 112 points to the runtime entry address 123b of the slave core 112 at boot time, where the runtime entry address 123b is used to indicate the kernel of the operating system 2 that needs to be run from the core 112 at boot time.
  • the storage address of the image file in the memory section 122 is used to indicate the kernel of the operating system 2 that needs to be run from the core 112 at boot time.
  • the runtime entry address pointer 1233 of the primary core 1 11 points to the runtime entry address 123c of the primary core 1 11 at startup, wherein the runtime entry address 123c is used to indicate the operation required to run the primary core 1 1 1 at startup.
  • the runtime entry address pointer for each processing core is preset for each processing core in UBoot before the system is started.
  • the system for supporting resource isolation under the multi-core architecture enables the operating system running on different processing cores of the multi-core processor to operate independently without affecting each other through the isolation of the operating system between the cores and the isolation of the memory segments.
  • a single processing core or an operating system running on it fails, it does not affect the operating system running on other processing cores or other processing cores, thereby taking advantage of the high integration degree and low integration cost of the multi-core processor.
  • the fault domain of the multi-core processor is maintained on a single hard disk and has high reliability.
  • the processor 11 stores the kernel image file of the operating system that needs to be executed by each processing core in the memory segment of each processing core, and includes at least the following two methods:
  • the boot loader 111 1 stores the kernel image files of the operating systems that need to be run by the processing cores in the memory sections of the processing cores according to the operation information 123a.
  • the boot loader 11 11 stores, according to the operation information 123a, a kernel image file of an operating system that needs to be run by at least one processing core of the processor into a memory segment of the processing core, where the processing core runs the The kernel image file of the operating system is stored in the memory segment of the remaining processing core according to the running information, and the kernel image file of the operating system corresponding to the remaining processing cores of the operating system is stored separately. .
  • the boot loader 11 11 will be based on the operation information 123a.
  • the kernel image file of the operating system that the at least one processing core of the processor needs to run is stored in the memory segment of the processor.
  • the boot loader 11 11 will start the host core 11 according to the operation information 123a.
  • the kernel image file of the operating system 1 that needs to be run is stored in the memory segment 121 allocated for the startup main core 1 11; then, at startup, the main core 11 1 runs the kernel image file of the operating system 1 in the memory segment 121; Then, at startup, the main core 1 11 stores the kernel image file of the operating system 2 that needs to be run from the core 112 at boot time to the memory segment 122 of the core 1 12 at startup by the running operating system 1 according to the operation information 123a.
  • the kernel image files of the operating system that each processing core needs to run are expanded in their respective memory segments.
  • this embodiment exemplarily describes the main core 1 11 as the processing core that runs the operating system first, but those skilled in the art should understand that the processing core that starts the operating system first is not limited to booting.
  • any processing core of the processor 11 may be determined to be the first to start the processing core running the operating system by, for example, a pre-specified manner.
  • the system for supporting resource isolation in a multi-core architecture expands a memory segment of a different processing core by expanding a kernel image file of an operating system that needs to be run in each processing core in a respective memory segment.
  • the kernel image files of the operating systems that each needs to run, and the resources on each memory segment are isolated from each other.
  • the correspondence between the processing cores recorded in the operation information and the operating systems includes at least the following two relationships:
  • Correspondence 1 A processing core group consisting of at least two processing cores runs a kernel image file of the same operating system. Optionally, all processing cores constituting the processing core group share the same segment of memory.
  • a processing core group consisting of at least two processing cores runs a kernel image file of the same operating system. All processing cores that make up the processing core group can share the same segment of memory.
  • the number of processing core groups can be more than one, and the operating systems of the respective processing core groups are independent of each other, and different memory segments are allocated for different operating systems, so that the failure of a single operating system does not affect other processing cores.
  • the group or the operating system running on it implements the fault domain of the multi-core processor to be maintained on a single hard disk.
  • Correspondence 2 The kernel image files of the operating systems that operate differently from each other.
  • the operation information there may be a situation in the processor 11 that the processing core group and the independent single processing core exist simultaneously.
  • independent operating systems are run on the processing core group or the independent single processing core, and the inter-core operating system isolation is realized.
  • each processing core of the processor elects a runtime main core in each processing core according to a preset election algorithm; and the runtime main core is configured to perform arbitration control of the I/O resources.
  • the runtime inserts data that requires an I/O operation from the core into the shared memory segment, and notifies the runtime primary core of the memory address associated with the I/O operation, so that the operation is performed.
  • the main core calls its own local physical drive, the I/O operation is performed on the external device.
  • the runtime calls its own local physical drive from the core to perform I/O operations on the external device.
  • FIG. 3 is a schematic structural diagram of a system for supporting resource isolation in a multi-core architecture according to Embodiment 2 of the present invention. This embodiment is implemented based on the above embodiment.
  • the system 20 for supporting resource isolation in a multi-core architecture of the present embodiment includes: a processor 21 and a memory space 22, wherein: the processor 21 includes a boot master core 111, a boot-time slave core 112, and a boot time.
  • the boot loader 1111 is set in the main core 111 at startup; and, at the startup, the main core 111 and the boot-time slave core 112 respectively run the operating system 1 and the operating system 2, and the boot-time slave core 211 and the core 212 constitute a processing core group 214, and the processing core group 214 runs the same operating system 3; the main core 111 corresponds to the memory segment 121 when starting, and the memory segment 122 corresponds to the core 112 when starting, and the core group 214 is processed. Corresponding to the memory section 221, the information is recorded in the operation information.
  • the main core 111 runs the operating system 1 at startup, and the size and starting address of the memory segment 121 allocated for the main core 111 at startup; (2) startup The operating system 2 is run from the core 112, the size and starting address of the memory segment 122 from the core 112 at startup; (3) the processing core group 214 runs the operating system 3, and the size of the memory segment 221 of the processing core group 214 is initial address.
  • the memory section 121, the memory section 122, the memory section 221, and the shared memory section 123 mutually realize memory section isolation.
  • each processing core is in a spin state.
  • the spin state means that the processing core is idling and waiting for an external event to wake up.
  • the processor 21 passes the boot loader 1 11 1, according to the correspondence between each processing core and each operating system recorded in the operation information, the size of each memory segment, and the start address. , using the boot load mode or the download mode, store the kernel image files of the operating systems that need to be run by each processing core into the memory segments of each processor, and write the runtime entry addresses of the processing cores into the shared memory respectively.
  • the boot loader 11 11 completes the device initialization; the processor 21 passes the boot loader 1 11 1, according to the correspondence between each processing core and each operating system recorded in the operation information, the size of each memory segment, and the start address. , using the boot load mode or the download mode, store the kernel image files of the operating systems that need to be run by each processing core into the memory segments of each processor, and write the runtime entry addresses of the processing cores into the shared memory respectively.
  • the processing core that starts the operating system first is preset to be the primary core 1 11 at startup, but is not limited thereto.
  • the processing core that starts the operating system first may also be preset as the processor 11 Other processing cores.
  • the main core 11 1 reads its own runtime entry address pointer, checks whether the valid physical address is valid, and if so, jumps to the runtime entry address of the boot master core 11 1 pointed to by the runtime entry address pointer.
  • Run operating system 1 by running the kernel image file of operating system 1.
  • the main core 11 1 wakes up the processing core to be started through the inter-core communication mechanism; each of the processing cores to be started reads their respective runtime entry address pointers to check whether a valid physical address, and if so, jumps Run the corresponding operating system by running the kernel image file of the corresponding operating system to the runtime entry address pointed to by the respective runtime entry address pointer.
  • each processing core jumps to the running information address to read the running information, and learns the operating system that needs to run, the size of the allocated memory segment, and the starting address, so that each processing core can only operate.
  • the boot loader 1 11 1 on the main core 1 11 stores the kernel image files of the operating systems that need to be run by each processing core or processing core group into the memory segments of each processing core or processing core group, and then each processing The core can be restarted, hibernated, or shut down independently without affecting the normal operation of other processing cores, especially when a single processing core or its operating system fails, without affecting other processing cores or operating systems running on them. , to achieve isolation between the nuclear operating system.
  • An optional implementation scenario is as follows: When processing a core independent restart, only need to reset, read the corresponding runtime entry address pointer to obtain a corresponding runtime entry address, and run an operating system stored in the memory segment of the processing core. Kernel image file, which does not depend on other processing core operations As a system.
  • Another optional implementation scenario is as follows: During the running of the system, for a processing core, other processing cores can modify the running information according to the system requirements, and the processing core obtains the reset after the running information is changed, and restarts when reading.
  • the new run information in the run information address is retrieved, the new run information is learned, and the reassigned operating system is run by reading the runtime entry address in the runtime entry address pointer.
  • the processing core a of the multi-core processor has occupied a segment of memory, and the operating system A is running on it, and the processing core b is in a spin state; the processing core c can be based on the system.
  • the running status modifies the running information, and re-specifies in the modified running information: the processing core a and the processing core b constitute the processing core group T, and run the same operating system on the processing core group, and allocate to the processing core The size of the memory segment of the group, and the starting address of the memory segment.
  • the processing core a After processing the core a to know that the running information is changed, optionally, the processing core a first unloads the operating system A running on the processing core a, releases the occupied memory segment, and processes the core a to restart.
  • the processing core group T (processing core a and processing core b) runs operating system B according to the modified running information and occupies a new memory segment.
  • each processing core or processing core group runs an independent operating system, thereby realizing memory segment isolation and inter-core operating system isolation.
  • the runtime main core refers to a processing core that can be collectively controlled and arbitrated by each processing core after each processing core of the processor 21 is started; the runtime main core is responsible for uniformly performing arbitration control of I/O resources.
  • the runtime main core is determined by each processing core of the processor 21 in each processing core according to a preset election algorithm. As shown in FIG.
  • the four processing cores in the running state constitute A cluster in which the four processing cores pass the inter-core communication, run an election algorithm, such as the PAXOS algorithm, and determine the runtime main core.
  • the election result is:
  • the main core 111 is elected as the runtime main core at startup.
  • the other processing cores are runtime nuclei.
  • the runtime main core elected by the cluster through multi-core negotiation is not limited to the main core at startup, which may be any processing core. This embodiment is only exemplary.
  • the main core at the time of startup is given as the running main core of the election, but the invention is not limited thereto.
  • the cluster that handles the core re-elects a new runtime main core, and the uniqueness of the main core at runtime is determined by the choice.
  • Algorithms are used to guarantee, for example, the PAXOS algorithm.
  • the main core at runtime is responsible for the unified arbitration control of I/O resources. All I/O resources and the use of coprocessor resources need to be authorized by the runtime main core.
  • the runtime When the runtime needs to access the external device 23 from the core, the runtime sends a resource usage request from the core to the runtime primary core; the runtime primary core uses the resource exclusively based on the resource usage request, based on the system resource usage and the resource allocation policy. After the ruling, the resource request response is sent from the core to the runtime; after receiving the resource request response from the core, the runtime obtains the use authorization of the I/O resource, and starts the I/O operation on the external device 23. .
  • the runtime main core can call its own local physical drive when the system resource usage and resource allocation policy allow, and perform I/O operations on the external device.
  • the implementation of accessing the external device 23 from the core using I/O resources at each runtime may include at least the following two modes: mode 1: the data from the core that needs the I/O operation is put into the shared memory segment from the core, and the memory address associated with the I/O operation is notified to the operation.
  • mode 1 the data from the core that needs the I/O operation is put into the shared memory segment from the core, and the memory address associated with the I/O operation is notified to the operation.
  • the main core so that the runtime main core calls its own local physical drive to perform the I/O operation on the external device.
  • Method 2 The runtime calls its own local physical drive from the core to perform I/O operations on the external device.
  • FIG. 4a is a schematic diagram of an implementation of checking a resource isolation system in a multi-core architecture according to a second embodiment of the present invention
  • FIG. 4 is a schematic diagram of a system for supporting resource isolation in a multi-core architecture according to Embodiment 2 of the present invention
  • Another implementation diagram of the runtime access from the check external device is a schematic diagram of an implementation of checking a resource isolation system in a multi-core architecture according to Embodiment 2 of the present invention.
  • the runtime puts data requiring I/O operations from the core 402 into the shared memory segment, and notifies the runtime master core 401 of the memory address associated with the I/O operation to enable operation.
  • the main core 401 calls its own local physical drive 4011 to perform the I/O operation on the external device 23.
  • the I/O operation of the external device 23 from the core 402 at runtime is accomplished by the runtime master core 401 agent.
  • the runtime slave core 402 can put the data requiring the current I/O operation into the shared memory segment through the shared memory mode, and notify the runtime main core 401 of the memory address associated with the I/O operation; the runtime master The core 401 receives the notification information sent from the core 402 at runtime, and calls the local physical driver 4011 to send the data to the external device 23 through the I/O resource for access.
  • the runtime main core 401 performs an I/O operation on the external device 23. And release the I/O resources and related resources of the external device 23 after the access ends.
  • the runtime calls its own local physical drive 4021 from the core 402 to perform I/O operations on the external device 23.
  • the runtime master core 401 approves the use of the I/O resource from the core 402 by the runtime master core 401; the runtime slave core 402 is based on the runtime master core 401.
  • the resource request response sent is accessed by the external device assigned to it by the through mode, including the I/O through operation of the external device 23, and the I/O resource operation is directly performed by calling the local physical drive 4021.
  • Each processing core performs an I/O operation on the external device 23 in a straight-through manner, and releases the control of the I/O resource to the runtime main core 401 after the operation is completed, ⁇ , notifying the runtime that the main core 401 has completed the I to the external device 23. /O operation;
  • the runtime main core 401 releases the I/O resources and related resources of the external device 23 according to the notification, so as to release the resources to other processing cores for use.
  • the runtime primary core maintains state peer information from the core at runtime.
  • the primary core finds that a processing core cannot be contacted. If the primary core has allocated external device resources to the processing core that cannot be contacted at this time, the primary core will reclaim the external device resources.
  • the system for supporting resource isolation under the multi-core architecture provided by the foregoing embodiment of the present invention is responsible for uniformly performing arbitration control of I/O resources through the main core of the operation, so that each processing core accesses the external device by using I/O resources. It should be noted that the system for supporting resource isolation under the multi-core architecture provided by the foregoing embodiment of the present invention is also used to implement access to common functional components for processing, and the public function component may at least include coprocessor resources. For the implementation of the arbitration application of the shared coprocessor resource, refer to the description of the foregoing embodiment, and details are not described herein again.
  • the system for supporting resource isolation in a multi-core architecture is responsible for uniformly performing arbitration control of I/O resources by electing a runtime core in each processing core to implement I/O resource isolation.
  • the unified I/O capability of the multi-core processor and the scheduling control of the coprocessor are realized in the case where the operating systems of the processing cores or the processing core groups operate independently of each other, thereby ensuring that the fault domain of the multi-core processor is maintained at Single hard drive.
  • FIG. 5 is a flowchart of a method for supporting resource isolation in a multi-core architecture according to Embodiment 3 of the present invention.
  • the method of this embodiment is applied to a system that supports resource isolation under a multi-core architecture, including a processor and a memory space, where: the processor includes a plurality of processing cores, and the plurality of processing cores include a startup master core and at least a boot-time slave core; the memory space includes a shared memory segment, and a memory segment of each processing core; the shared memory segment stores operation information, and a runtime entry address of each processing core; the operation information includes a correspondence between each processing core and each operating system, a size of each memory segment, and a starting address; and a runtime entry address of each processing core, The storage address of the kernel image file of the operating system that is required to be run by each processing core in the respective memory segment.
  • the method in this embodiment includes:
  • the processor stores, in a memory segment of each processing core, a kernel image file of an operating system that needs to be run by each processing core, and writes a runtime entry address of each processing core into the shared memory segment.
  • the processing cores to be started respectively acquire respective runtime entry addresses, and run kernel image files of operating systems stored in respective memory segments.
  • each processing core of the processor elects, according to a preset election algorithm, a runtime main core in each processing core; the runtime main core is configured to perform arbitration control on input/output I/O resources. .
  • the runtime inserts data that requires an I/O operation from the core into the shared memory segment, and notifies the runtime primary core of the memory address associated with the I/O operation, so that the operation is performed.
  • the main core calls its own local physical drive, the I/O operation is performed on the external device.
  • the runtime calls its own local physical drive from the core to perform I/O operations on the external device.
  • the startup loader is configured in the main core, and the processor stores the kernel image files of the operating system that are required to be executed by the processing cores into the memory segments of the processing cores, including:
  • the boot loader stores, according to the operation information, a kernel image file of an operating system that needs to be run by each processing core in a memory segment of each processing core;
  • the startup loader is configured in the main core, and the processor stores the kernel image files of the operating system that are required to be executed by the processing cores into the memory segments of the processing cores, including:
  • the boot loader stores, according to the operation information, a kernel image file of an operating system that needs to be run in at least one processing core memory segment of the processor, and runs a kernel image file of the operating system;
  • the processing core of the system stores the kernel image files of the operating system corresponding to the remaining processing cores of the processor that are required to run the operating system in the memory segments of the remaining processing cores according to the operation information.
  • the processing core group formed by the at least two processing cores runs a kernel image file of the same operating system, and all processing cores constituting the processing core group share the same segment of memory. Section; or, each processing core runs a kernel image file of an operating system that is different from each other.
  • the method for supporting resource isolation in a multi-core architecture enables the operating system running on different processing cores of the multi-core processor to be separated by inter-core operating system isolation, memory segment isolation, and I/O resource isolation. Independent operation does not affect each other, thus making full use of the advantages of high integration of multi-core processors and low integration cost, and the fault domain of multi-core processors is maintained on a single hard disk with high reliability.

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Computer Security & Cryptography (AREA)
  • Stored Programmes (AREA)
  • Multi Processors (AREA)

Abstract

本发明实施例提供一种支持多核架构下资源隔离的方法及系统。本发明实施例提供的支持多核架构下资源隔离的方法及系统，通过核间操作系统隔离、内存区段隔离、I/O资源隔离的方式，使得在多核处理器的不同处理核上运行的操作系统能够独立运行而互不影响，从而，充分利用了多核处理器高集成度、综合成本低的优势，实现了多核处理器的故障域维持在单块硬盘，具有较高的可靠性。

Description

支持多核架构下资源隔离的方法及系统 技术领域 本发明实施例涉及计算机技术， 尤其涉及一种支持多核架构下资源隔离 的方法及系统。 背景技术 基于大规模统一资源池的云存储系统， 以数据存储和管理为核心， 支持 多业务的统一部署， 高效利用磁盘， 可按需供给减少投资损失， 通过合理调 度实现有效利用资源、 降低综合能耗。
现有技术采用多核 ARM处理器带少量硬盘的服务器， 例如基于精简指 令集 (Reduced Instruction Set Computing, 简称 RISC)的 ARM服务器方式， 可以发挥 ARM处理器低功耗、 高集成度、 综合成本低的优势。
然而， 现有技术的多核 ARM处理器带多块硬盘的情况， 多核处理器上 运行一个操作系统， 在该操作系统失效时， 服务器的失效粒度为多块硬盘， 并且由于单块硬盘的容量大而输入 /输出（Input/Output, 简称 I/O)吞吐带宽 却较小， 使得数据恢复量以及网络传输数据量都以倍数增长， 故障恢复粒度 较粗， 给系统造成较大的压力。 发明内容 本发明实施例提供一种支持多核架构下资源隔离的方法及系统， 以使多 核处理器的故障域维持在单块硬盘。
第一方面， 本发明实施例提供一种支持多核架构下资源隔离的系统， 该 系统包括： 处理器， 所述处理器包括多个处理核， 所述多个处理核中包括 一个启动时主核以及至少一个启动时从核； 内存空间， 所述内存空间包括 共享内存段， 以及各处理核的内存区段； 所述共享内存段中存储有运行信 息， 以及各处理核的运行时入口地址； 所述运行信息包括各处理核与各操 作系统之间的对应关系、 各内存区段的大小以及起始地址； 所述各处理核 的运行时入口地址， 用于指示各处理核所需要运行的操作系统的内核镜像 文件在各自的内存区段中的存储地址； 其中， 所述处理器将各处理核所需 要运行的操作系统的内核镜像文件分别存储到各处理核的内存区段中， 并 将各处理核的运行时入口地址分别写入到所述共享内存段中； 待启动的处 理核分别获取各自的运行时入口地址， 并运行存储在各自的内存区段中的 操作系统的内核镜像文件。
在第一方面的第一种可能的实现方式中， 所述处理器的各处理核根据 预设的选举算法在各处理核中选举确定运行时主核； 所述运行时主核， 用 于进行输入 /输出 I/O资源的仲裁控制。
根据第一方面的第一种可能的实现方式， 在第二种可能的实现方式 中， 运行时从核将需要 I/O操作的数据放入所述共享内存段， 并将与所述 I/O 操作相关的内存地址通知所述运行时主核， 以使所述运行时主核调用 自身的本地物理驱动， 对外部设备进行所述 I/O操作。
根据第一方面的第一种可能的实现方式， 在第三种可能的实现方式 中， 运行时从核调用自身的本地物理驱动， 对外部设备进行 I/O操作。
根据第一方面、第一方面的第一种至第三种可能的实现方式的任意一 种， 在第四种可能的实现方式中， 所述启动时主核内设置有启动加载器； 所述处理器将各处理核所需要运行的操作系统的内核镜像文件分别存储 到各处理核的内存区段中， 包括： 所述启动加载器根据所述运行信息， 将 各处理核所需要运行的操作系统的内核镜像文件分别存储到各处理核的 内存区段中。
根据第一方面、第一方面的第一种至第三种可能的实现方式的任意一 种， 在第五种可能的实现方式中， 所述启动时主核内设置有启动加载器； 所述处理器将各处理核所需要运行的操作系统的内核镜像文件分别存储 到各处理核的内存区段中， 包括： 所述启动加载器根据所述运行信息， 在 所述处理器的至少一个处理核的内存区段中存储所需要运行的操作系统 的内核镜像文件， 运行所述操作系统的内核镜像文件； 所述运行操作系统 的处理核根据所述运行信息， 将所述处理器的需要运行操作系统的其余处 理核所对应的操作系统的内核镜像文件分别存储到各所述其余处理核的 内存区段中。
根据第一方面、第一方面的第一种至第五种可能的实现方式的任意一 种， 在第六种可能的实现方式中， 由至少两个处理核构成的处理核组运行 相同的操作系统的内核镜像文件， 并且， 所述构成所述处理核组的所有处 理核共用同一段内存区段； 或者， 各处理核运行互不相同的操作系统的内 核镜像文件。
第二方面， 本发明实施例提供一种支持多核架构下资源隔离的方法， 应 用于包括处理器和内存空间的支持多核架构下资源隔离的系统， 其中： 所 述处理器包括多个处理核， 所述多个处理核中包括一个启动时主核以及至 少一个启动时从核； 所述内存空间包括共享内存段， 以及各处理核的内存 区段； 所述共享内存段中存储有运行信息， 以及各处理核的运行时入口地 址； 所述运行信息包括各处理核与各操作系统之间的对应关系、 各内存区 段的大小以及起始地址； 所述各处理核的运行时入口地址， 用于指示各处 理核所需要运行的操作系统的内核镜像文件在各自的内存区段中的存储 地址；
所述支持多核架构下资源隔离的方法包括：
所述处理器将各处理核所需要运行的操作系统的内核镜像文件分别 存储到各处理核的内存区段中， 并将各处理核的运行时入口地址分别写入 所述共享内存段中；
待启动的处理核分别获取各自的运行时入口地址， 并运行存储在各自 的内存区段中的操作系统的内核镜像文件。
在第二方面的第一种可能的实现方式中， 所述处理器的各处理核根据 预设的选举算法在各处理核中选举确定运行时主核； 所述运行时主核， 用 于进行输入 /输出 I/O资源的仲裁控制。
根据第二方面的第一种可能的实现方式， 在第二种可能的实现方式 中， 运行时从核将需要 I/O操作的数据放入所述共享内存段， 并将与所述 I/O 操作相关的内存地址通知所述运行时主核， 以使所述运行时主核调用 自身的本地物理驱动， 对外部设备进行所述 I/O操作。
根据第二方面的第一种可能的实现方式， 在第三种可能的实现方式 中，运行时从核调用自身的本地物理驱动，对外部设备进行所述 I/O操作。
根据第二方面、第二方面的第一种至第三种可能的实现方式的任意一 种， 在第四种可能的实现方式中， 所述启动时主核内设置有启动加载器； 所述处理器将各处理核所需要运行的操作系统的内核镜像文件分别存储 到各处理核的内存区段中， 包括：
所述启动加载器根据所述运行信息， 将各处理核所需要运行的操作系 统的内核镜像文件分别存储到各处理核的内存区段中。
根据第二方面、第二方面的第一种至第三种可能的实现方式的任意一 种， 在第五种可能的实现方式中， 所述启动时主核内设置有启动加载器； 所述处理器将各处理核所需要运行的操作系统的内核镜像文件分别 存储到各处理核的内存区段中， 包括：
所述启动加载器根据所述运行信息， 在所述处理器的至少一个处理核 的内存区段中存储所需要运行的操作系统的内核镜像文件， 运行所述操作 系统的内核镜像文件； 所述运行操作系统的处理核根据所述运行信息， 将 所述处理器的需要运行操作系统的其余处理核所对应的操作系统的内核 镜像文件分别存储到各所述其余处理核的内存区段中。
根据第二方面、第二方面的第一种至第五种可能的实现方式的任意一 种， 在第六种可能的实现方式中， 由至少两个处理核构成的处理核组运行 相同的操作系统的内核镜像文件， 并且， 所述构成所述处理核组的所有处 理核共用同一段内存区段； 或者， 各处理核运行互不相同的操作系统的内 核镜像文件。
本发明实施例提供的支持多核架构下资源隔离的方法及系统， 通过核间 操作系统隔离、 内存区段隔离、 I/O资源隔离的方式， 使得在多核处理器的不 同处理核上运行的操作系统能够独立运行而互不影响， 从而， 充分利用了多 核处理器高集成度、 综合成本低的优势， 实现了多核处理器的故障域维持 在单块硬盘， 具有较高的可靠性。 附图说明
图 la为本发明实施例一提供的支持多核架构下资源隔离的系统的结构示 意图；
图 lb为采用本发明实施例一的支持多核架构下资源隔离的系统的云 存储系统的拓扑结构示意图；
图 2为图 la所示的支持多核架构下资源隔离的系统中的共享内存段 的局部结构示意图；
图 3为本发明实施例二提供的支持多核架构下资源隔离的系统的结构示 意图；
图 4a为本发明实施例二提供的支持多核架构下资源隔离的系统的运 行时从核对外部设备进行访问的一实现示意图；
图 4b为本发明实施例二提供的支持多核架构下资源隔离的系统的运 行时从核对外部设备进行访问的另一实现示意图；
图 5 为本发明实施例三提供的支持多核架构下资源隔离的方法的流程 图。 具体实施方式 实施例一
图 la为本发明实施例一提供的支持多核架构下资源隔离的系统的结 构示意图。 图 la所示的支持多核架构下资源隔离的系统 10适用于基于大 规模统一资源池的云存储系统。 图 lb 为采用本发明实施例一的支持多核 架构下资源隔离的系统的云存储系统的拓扑结构示意图。 如图 lb所示， 云存储系统 100包括： 交换机 102、 至少一个支持多核架构下资源隔离的 系统 10、 至少一个应用服务器 101。 其中， 应用服务器 101与交换机 102 连接， 支持多核架构下资源隔离的系统 10与交换机 102连接。
如图 la所示， 本实施例的支持多核架构下资源隔离的系统 10包括： 处理器 1 1和内存空间 12， 其中：
处理器 11， 包括多个处理核： 一个启动时主核 1 11以及至少一个启动 时从核 1 12；
内存空间 12， 包括共享内存段 123、启动时主核 11 1的内存区段 121、 启动时从核 112的内存区段 122; 共享内存段 123中存储有运行信息， 以 及各处理核的运行时入口地址； 所述运行信息包括各处理核与各操作系统 之间的对应关系、 各内存区段的大小以及起始地址； 所述各处理核的运行 时入口地址， 用于指示各处理核所需要运行的操作系统的内核镜像文件在 各自的内存区段中的存储地址；
其中， 处理器 11 将各处理核所需要运行的操作系统的内核镜像文件 分别存储到各处理核的内存区段中， 并将各处理核的运行时入口地址写入 共享内存段 123中； 待启动的处理核分别获取各自的运行时入口地址， 并 运行存储在各自的内存区段中的操作系统的内核镜像文件。
具体地， 如图 la所示， 处理器 11是包括多个处理核的多核处理器， 例如可以采用 ARM或 Intel ATOM处理器， 但是本发明并不以此为限。处 理器 11包括多个处理核， 图 la示例性的示出处理器 11包括启动时主核 111以及一个启动时从核 112的情形， 然而， 处理器 11可以包括一个或多 数个启动时从核， 在此不再赘述。 启动时主核 111， 是指由硬件预先确定 的设置启动加载器 1111 的处理核， 并且启动时主核 111 能够触发其他处 理核启动并运行； 启动时从核 112， 是指处理器 11在启动时， 通过启动时 主核 111触发而启动的其他处理核。 具体应用中， 所述启动时主核内设置 的启动加载器 1111， 例如是 UBoot, 可完成设备初始化， 也可以将操作系 统的内核镜像文件存储到需要运行该操作系统的处理核所的内存区段中。 图 la示出了启动时主核 111、 启动时从核 112分别与操作系统 1、 操作系 统 2的对应关系，其中，操作系统 1、操作系统 2可以是 LINUX、 Windows、 Solaris DOS、 OS/2、 UNIX、 XENIX Netware, 或者同一操作系统的不 同版本， 并且， 操作系统 1和操作系统 2可以为完全相同的操作系统， 也 可以为同一种类操作系统的不同版本， 或者不同种类的操作系统， 但本发 明并不以此为限。
图 2为图 la所示的支持多核架构下资源隔离的系统中的共享内存段 的局部结构示意图。 如图 la和图 2所示， 共享内存段 123中存储有运行 信息 123a、启动时从核 112的运行时入口地址 123b， 以及启动时主核 111 的运行时入口地址 123c; 其中， 运行信息 123a， 记录了内存区段的规划 信息， 至少包括： 各处理核与各操作系统之间的对应关系、 各内存区段的 大小以及起始地址， 即如下信息： （1 ) 启动时主核 111运行操作系统 1， 为启动时主核 111分配的内存区段 121 的大小和起始地址； （2 ) 启动时 从核 112运行操作系统 2， 启动时从核 112的内存区段 122的大小和起始 地址； （3 ) 共享内存段 123 的大小和起始地址。 所述各内存区段相互独 立， 相互隔离， 实现了为不同的操作系统分配相互独立的内存区段。 如果未 指定各内存区段的起始地址， 将缺省从地址 0开始， 或者从前一个内存区 段的结束地址开始作为该内存区段的起始地址。 运行信息地址 1231 是运 行信息 123a在共享内存段 123 中的存储地址， 各处理核都需要遵循运行 信息地址 1231的约定， 通过运行信息地址 1231査询运行信息， 可选的， 在每个处理核存储的操作系统的内核镜像文件中分别指示各个处理核的 运行信息地址， 并且运行信息可以在系统运行过程中动态修改和调整。 启 动时从核 112的运行时入口地址指针 1232指向启动时从核 112的运行时 入口地址 123b， 其中， 运行时入口地址 123b， 用以指示启动时从核 112 所需要运行的操作系统 2的内核镜像文件在内存区段 122中的存储地址。 启动时主核 1 11 的运行时入口地址指针 1233指向启动时主核 1 11 的运行 时入口地址 123c， 其中， 运行时入口地址 123c， 用以指示启动时主核 1 1 1 所需要运行的操作系统 1的内核镜像文件在内存区段 121中的存储地址。 每个处理核的运行时入口地址指针是系统启动前在 UBoot 中为每个处理 核分别预设的。
本发明实施例提供的支持多核架构下资源隔离的系统， 通过核间操作系 统隔离、 内存区段隔离的方式， 使得在多核处理器的不同处理核上运行的操 作系统能够独立运行而互不影响， 当单个处理核或其上运行的操作系统失效 时， 不会影响到其他处理核或其他处理核上运行的操作系统， 从而， 充分利 用了多核处理器高集成度、 综合成本低的优势， 实现了多核处理器的故障 域维持在单块硬盘， 具有较高的可靠性。
在上述实施例的基础上， 处理器 11将各处理核所需要运行的操作系统 的内核镜像文件存储到各处理核的内存区段中的实现方式， 至少包括以下 两种方式：
方式 1 : 启动加载器 111 1根据运行信息 123a， 将各处理核所需要运 行的操作系统的内核镜像文件分别存储到各处理核的内存区段中。
方式 2: 启动加载器 11 11 根据运行信息 123a， 将所述处理器的至少 一个处理核所需要运行的操作系统的内核镜像文件存储到该处理核的内 存区段中， 该处理核运行所述操作系统的内核镜像文件； 所述运行操作系 统的处理核根据运行信息， 将需要运行操作系统的其余处理核所对应的操 作系统的内核镜像文件分别存储到到余处理核所的内存区段中。
具体地， 在实现方式 2中， 启动加载器 11 11根据运行信息 123a， 将 所述处理器的至少一个处理核所需要运行的操作系统的内核镜像文件存 储到该处理器的内存区段中， 例如， 启动加载器 11 11根据运行信息 123a， 将启动时主核 1 11所需要运行的操作系统 1的内核镜像文件存储到为启动 时主核 1 11分配的内存区段 121中； 接着， 启动时主核 11 1运行内存区段 121中的操作系统 1的内核镜像文件； 随后， 启动时主核 1 11通过运行的 操作系统 1，根据运行信息 123a将启动时从核 112所需要运行的操作系统 2的内核镜像文件存储到启动时从核 1 12的内存区段 122中， 从而将每个 处理核需要运行的操作系统的内核镜像文件在各自的内存区段中展开。 需 要说明的是， 本实施例示例性地描述了启动时主核 1 11作为最先运行操作 系统的处理核， 但是本领域技术人员应该理解， 最先启动运行操作系统的 处理核并不只限于启动时主核 11 1，处理器 11的任意处理核都可能通过例 如预先指定的方式确定为最先启动运行操作系统的处理核。
本发明实施例提供的支持多核架构下资源隔离的系统，通过将每个处理 核需要运行的操作系统的内核镜像文件在各自的内存区段中展开， 使得不 同的处理核的内存区段中存储各自需要运行的操作系统的内核镜像文件， 并且各内存区段上的资源是相互隔离的。
在上述实施例的基础上， 运行信息中记录的各处理核与各操作系统之 间的对应关系， 至少包括以下两种关系：
对应关系 1 :由至少两个处理核构成的处理核组运行相同的操作系统的 内核镜像文件。 可选的， 构成所述处理核组的所有处理核共用同一段内存 区段。
具体地， 由至少两个处理核构成的处理核组运行相同的操作系统的内 核镜像文件。 构成所述处理核组的所有处理核可以共用同一段内存区段。 处理核组的数目可以不止一个， 并且各个处理核组各自运行的操作系统相 互独立， 为不同的操作系统分配相互独立的内存区段， 使得单个操作系统的 失效， 不会影响到其他的处理核组或其上运行的操作系统， 实现了多核处理 器的故障域维持在单块硬盘。
对应关系 2: 各处理核运行互不相同的操作系统的内核镜像文件。
可选的， 根据运行信息， 处理器 1 1中可以存在处理核组和独立的单个 处理核同时存在的情形。 在上述实施例的基础上， 在处理核组或独立的单个处理核上运行着相 互独立的操作系统， 实现了核间操作系统隔离。 鉴于多核处理器的 I/O资源 以及协处理器全局共享， 当各处理核启动后， 需要在各处理核中选择一个 处理核进行统一 I/O资源的仲裁控制。 进一歩， 所述处理器的各处理核根 据预设的选举算法在各处理核中选举确定运行时主核； 所述运行时主核， 用于进行 I/O资源的仲裁控制。
可选的， 运行时从核将需要 I/O操作的数据放入所述共享内存段， 并 将与所述 I/O操作相关的内存地址通知所述运行时主核， 以使所述运行时 主核调用自身的本地物理驱动， 对外部设备进行所述 I/O操作。
可选的， 运行时从核调用自身的本地物理驱动， 对外部设备进行 I/O 操作。
下面通过一个具体的实施例对上述支持多核架构下资源隔离的系统 的具体实现， 进行详细的说明。
实施例二
图 3为本发明实施例二提供的支持多核架构下资源隔离的系统的结构 示意图。 本实施例基于上述实施例来实现。 如图 3所示， 本实施例的支持 多核架构下资源隔离的系统 20包括： 处理器 21和内存空间 22， 其中： 处 理器 21， 包括启动时主核 111、 启动时从核 112、 启动时从核 211、 启动 时从核 212， 启动时主核 111内设置有启动加载器 1111 ; 并且， 启动时主 核 111与启动时从核 112分别运行操作系统 1与操作系统 2， 启动时从核 211和启动时从核 212组成处理核组 214， 处理核组 214运行同一个操作 系统 3 ; 启动时主核 111对应内存区段 121， 启动时从核 112对应内存区 段 122， 处理核组 214对应内存区段 221， 该些信息均记录在运行信息中。
具体地， 运行信息中记录的例如是以下的信息： （1 )启动时主核 111 运行操作系统 1， 为启动时主核 111分配的内存区段 121的大小和起始地 址； （2 ) 启动时从核 112运行操作系统 2， 启动时从核 112的内存区段 122的大小和起始地址； （3 )处理核组 214运行操作系统 3，处理核组 214 的内存区段 221的大小和起始地址。 在内存空间 22中， 内存区段 121、 内 存区段 122、 内存区段 221及共享内存段 123相互之间， 实现了内存区段 隔离。 系统启动后， 每个处理核处于自旋状态， 自旋状态是指处理核不停空 转， 等待外部事件唤醒。 启动加载器 11 11 完成设备初始化之后； 处理器 21 通过启动加载器 1 11 1， 根据运行信息中记录的各处理核与各操作系统 之间的对应关系、 各内存区段的大小以及起始地址， 使用启动加载模式或 下载模式， 将各处理核所需要运行的操作系统的内核镜像文件分别存储到 各处理器的内存区段中， 并将各处理核的运行时入口地址分别写入共享内 存段 123中。
在本实施例中， 最先启动运行操作系统的处理核预设为启动时主核 1 11， 但并不以此为限， 最先启动运行操作系统的处理核也可以预设为处 理器 11的其他处理核。
启动时主核 11 1读取自身的运行时入口地址指针， 检査是否有效物理 地址， 若是， 则跳转到该运行时入口地址指针所指向的启动时主核 11 1的 运行时入口地址， 运行操作系统 1的内核镜像文件， 从而运行操作系统 1。 启动时主核 11 1通过核间通信机制， 唤醒待启动的处理核； 各所述待启动 的处理核分别读取各自的运行时入口地址指针， 检査是否有效物理地址， 若是， 则跳转到各自的运行时入口地址指针所指向的运行时入口地址， 运 行对应的操作系统的内核镜像文件， 从而运行对应的操作系统。 其中， 各 处理核在执行过程中， 将跳转到运行信息地址读取运行信息， 获知各自需要 运行的操作系统、 分配的内存区段的大小以及起始地址， 从而， 各处理核只 可以操作共享内存段 123， 以及各自的内存区段。 因此， 本实施例的支持多 核架构下资源隔离的系统 20，实现了在处理器的不同的处理核或处理核组 上运行相互独立的操作系统， 并且只在系统启动时， 通过运行于启动时主 核 1 11上的启动加载器 1 11 1将各处理核或处理核组所需要运行的操作系 统的内核镜像文件存储到各处理核或处理核组的内存区段中， 之后， 每个 处理核可以独立进行重启、 休眠或关闭， 而并不会影响其他处理核的正常 运行， 尤其在单个处理核或其操作系统失效时， 也不会影响到其他处理核或 在其上运行的操作系统， 实现了核间操作系统隔离。
一种可选的实现场景为： 处理核独立重启时， 只需要复位， 读取对应 的运行时入口地址指针获取对应的运行时入口地址， 运行存储在该处理核 的内存区段中的操作系统的内核镜像文件， 其不用依赖于其他处理核的操 作系统。
另一种可选的实现场景为： 在系统运行过程中， 对于某一处理核， 其 他处理核可以根据系统需求修改运行信息， 该处理核获知运行信息改变后 进行复位， 重新启动时， 通过读取运行信息地址中的新的运行信息， 获知 新的运行信息， 并通过读取运行时入口地址指针中的运行时入口地址， 运 行重新指定的操作系统。 例如， 在系统启动后的某一时刻， 多核处理器的 处理核 a已经占用了一段内存区段， 并在其上运行着操作系统 A， 处理核 b处于自旋状态； 处理核 c可以根据系统运行状态对运行信息进行修改， 在修改后的运行信息中重新指定了：处理核 a和处理核 b构成处理核组 T、 并在处理核组 Τ上运行同一个操作系统 Β、分配给处理核组 Τ的内存区段 的大小， 以及内存区段的起始地址。 处理核 a获知运行信息改变后， 可选 的， 处理核 a首先将正在处理核 a上运行的操作系统 A卸载， 并释放占用 的内存区段， 处理核 a重新启动。 处理核组 T (处理核 a和处理核 b ) 根 据修改后的运行信息， 运行操作系统 B， 并占用一段新的内存区段。
处理器 21 的各处理核启动后， 各处理核或处理核组上运行着相互独 立的操作系统， 实现了内存区段隔离、 核间操作系统隔离。 鉴于多核处理器 的 I/O资源以及协处理器全局共享， 当各处理核启动后， 需要在处理器 21 的各处理核中选择一个运行时主核。 所述运行时主核是指处理器 21 的各 处理核启动后， 能够作为各处理核集中控制和仲裁的处理核； 所述运行时 主核负责统一进行 I/O资源的仲裁控制。 具体地， 运行时主核， 是由处理 器 21 的各处理核根据预设的选举算法在各处理核中选举确定的。 如图 3 所示，假设处理器 21的启动时主核 111、启动时从核 112、启动时从核 211 和启动时从核 212均处于运行状态， 那么这 4个处于运行状态的处理核构 成一个集群， 在该集群内， 这 4个处理核通过核间通信， 运行选举算法， 例如 PAXOS算法， 选举确定运行时主核， 例如选举结果为： 启动时主核 111被选举为运行时主核， 其他的处理核为运行时从核， 需要说明的是： 集群通过多核协商选举出的运行时主核并不只限于启动时主核， 其可能是 任一处理核， 本实施例只是示例性的给出启动时主核作为选举出的运行时 主核， 但是本发明并不以此为限。 当选举出的运行时主核失效时， 处理核 的集群重新选举一个新的运行时主核， 运行时主核的唯一性由所使用的选 举算法来保证， 例如 PAXOS算法。
运行时主核负责统一进行 I/O资源的仲裁控制， 所有的 I/O资源以及 协处理器资源使用都需要经过运行时主核的认可授权。
当运行时从核需要访问外部设备 23 时， 运行时从核向运行时主核发 送资源使用请求； 运行时主核根据该资源使用请求， 基于系统资源使用情 况和资源分配策略， 在排他性使用资源的裁决后， 向所述运行时从核发送 资源请求响应； 所述运行时从核接收到所述资源请求响应后， 获得 I/O资 源的使用授权， 开始对外部设备 23进行 I/O操作。
运行时主核在系统资源使用情况和资源分配策略允许时可以调用自 身的本地物理驱动， 对外部设备进行 I/O操作； 各运行时从核使用 I/O资 源对外部设备 23进行访问的实现方式， 至少可以包括以下两种方式： 方式 1 : 运行时从核将需要 I/O操作的数据放入所述共享内存段， 并 将与所述 I/O操作相关的内存地址通知所述运行时主核， 以使所述运行时 主核调用自身的本地物理驱动， 对外部设备进行所述 I/O操作。
方式 2: 运行时从核调用自身的本地物理驱动， 对外部设备进行 I/O 操作。
图 4a为本发明实施例二提供的支持多核架构下资源隔离的系统的运 行时从核对外部设备进行访问的一实现示意图； 图 4b 为本发明实施例二 提供的支持多核架构下资源隔离的系统的运行时从核对外部设备进行访 问的另一实现示意图。
如图 4a所示，运行时从核 402将需要 I/O操作的数据放入所述共享内 存段， 并将与所述 I/O操作相关的内存地址通知运行时主核 401， 以使运 行时主核 401调用自身的本地物理驱动 4011，对外部设备 23进行所述 I/O 操作。 运行时从核 402对外部设备 23进行 I/O操作， 是通过运行时主核 401代理完成。 运行时从核 402可以通过共享内存方式， 将需要本次 I/O 操作的数据放入共享内存段， 并将与所述 I/O操作相关的内存地址通知运 行时主核 401 ; 运行时主核 401接收运行时从核 402发送的通知信息， 调 用本地物理驱动 4011将数据通过 I/O资源发给外部设备 23， 进行访问， 例如运行时主核 401对外部设备 23进行 I/O操作， 并在访问结束后释放 I/O资源及外部设备 23的相关资源。 如图 4b所示， 运行时从核 402调用自身的本地物理驱动 4021， 对外 部设备 23进行 I/O操作。运行时从核 402需要对外部设备 23进行访问时， 通过控制仲裁方式， 由运行时主核 401批准运行时从核 402对 I/O资源的 使用； 运行时从核 402根据运行时主核 401发送的资源请求响应， 采用直 通方式对为其分配的外部设备进行访问，包括对外部设备 23进行 I/O的直 通操作，通过调用本地的物理驱动 4021直接进行 I/O资源的操作，也即各 处理核采用直通方式对外部设备 23进行 I/O操作，操作完成后释放 I/O资 源的控制给运行时主核 401， §Ρ , 通知运行时主核 401 已完成对外部设备 23的 I/O操作； 运行时主核 401根据所述通知， 释放 I/O资源及外部设备 23的相关资源， 以便将资源释放给其他处理核使用。
可选的， 运行时主核与运行时从核之间维持状态同歩信息。 当运行时 主核发现有某个处理核无法联系， 若此时， 运行时主核已经给该无法联系 的处理核分配了外部设备资源， 则运行时主核将收回该外部设备资源。 本 发明上述实施例提供的支持多核架构下资源隔离的系统， 通过运行时主核 负责统一进行 I/O资源的仲裁控制， 实现了各个处理核使用 I/O资源对外 部设备进行访问。 需要说明的是， 本发明上述实施例提供的支持多核架构 下资源隔离的系统， 也用于实现各个处理核对公共功能部件进行访问， 公 共功能部件至少可以包括协处理器资源。共享式的协处理器资源的仲裁应 用的实现方式具体参见上述实施例的描述， 在此不再赘述。
本发明实施例提供的支持多核架构下资源隔离的系统， 通过在各处理核 中选举运行时主核来负责统一进行 I/O资源的仲裁控制， 实现 I/O资源的 隔离。 在各处理核或处理核组上的运行的操作系统互相独立运行的情况 下， 实现了多核处理器中统一 I/O能力以及协处理器的调度控制， 保证了 多核处理器的故障域维持在单块硬盘。
实施例三
图 5 为本发明实施例三提供的支持多核架构下资源隔离的方法的流程 图。 本实施例的方法应用于包括处理器和内存空间的支持多核架构下资源 隔离的系统， 其中： 所述处理器包括多个处理核， 所述多个处理核中包括 一个启动时主核以及至少一个启动时从核； 所述内存空间包括共享内存 段， 以及各处理核的内存区段； 所述共享内存段中存储有运行信息， 以及 各处理核的运行时入口地址； 所述运行信息包括各处理核与各操作系统之 间的对应关系、 各内存区段的大小以及起始地址； 所述各处理核的运行时 入口地址， 用于指示各处理核所需要运行的操作系统的内核镜像文件在各 自的内存区段中的存储地址。 如图 5所示， 本实施例的方法包括：
501、 处理器将各处理核所需要运行的操作系统的内核镜像文件分别 存储到各处理核的内存区段中， 并将各处理核的运行时入口地址分别写入 所述共享内存段中。
502、 待启动的处理核分别获取各自的运行时入口地址， 并运行存储 在各自的内存区段中的操作系统的内核镜像文件。
可选的， 所述处理器的各处理核根据预设的选举算法在各处理核中选 举确定运行时主核； 所述运行时主核， 用于进行输入 /输出 I/O资源的仲裁 控制。
可选的， 运行时从核将需要 I/O操作的数据放入所述共享内存段， 并 将与所述 I/O操作相关的内存地址通知所述运行时主核， 以使所述运行时 主核调用自身的本地物理驱动， 对外部设备进行所述 I/O操作。
可选的， 运行时从核调用自身的本地物理驱动， 对外部设备进行 I/O 操作。
可选的， 所述启动时主核内设置有启动加载器； 所述处理器将各处理 核所需要运行的操作系统的内核镜像文件分别存储到各处理核的内存区 段中， 包括： 所述启动加载器根据所述运行信息， 将各处理核所需要运行 的操作系统的内核镜像文件分别存储到各处理核的内存区段中；
可选的， 所述启动时主核内设置有启动加载器； 所述处理器将各处理 核所需要运行的操作系统的内核镜像文件分别存储到各处理核的内存区 段中， 包括： 所述启动加载器根据所述运行信息， 在所述处理器的至少一 个处理核内存区段中存储所需要运行的操作系统的内核镜像文件， 运行所 述操作系统的内核镜像文件； 所述运行操作系统的处理核根据所述运行信 息， 将所述处理器的需要运行操作系统的其余处理核所对应的操作系统的 内核镜像文件分别存储到各所述其余处理核的内存区段中。
可选的， 由至少两个处理核构成的处理核组运行相同的操作系统的内 核镜像文件， 并且， 所述构成所述处理核组的所有处理核共用同一段内存 区段； 或者， 各处理核运行互不相同的操作系统的内核镜像文件。
本发明实施例提供的支持多核架构下资源隔离的方法， 通过核间操作系 统隔离、 内存区段隔离、 I/O资源隔离的方式， 使得在多核处理器的不同处理 核上运行的操作系统能够独立运行而互不影响， 从而， 充分利用了多核处理 器高集成度、 综合成本低的优势， 实现了多核处理器的故障域维持在单块 硬盘， 具有较高的可靠性。
本领域普通技术人员可以理解： 实现上述方法实施例的全部或部分歩 骤可以通过程序指令相关的硬件来完成， 前述的程序可以存储于一计算机 可读取存储介质中， 该程序在执行时， 执行包括上述方法实施例的歩骤； 而前述的存储介质包括： ROM、 RAM, 磁碟或者光盘等各种可以存储程 序代码的介质。
最后应说明的是： 以上各实施例仅用以说明本发明的技术方案， 而非 对其限制； 尽管参照前述各实施例对本发明进行了详细的说明， 本领域的 普通技术人员应当理解： 其依然可以对前述各实施例所记载的技术方案进 行修改， 或者对其中部分或者全部技术特征进行等同替换； 而这些修改或 者替换， 并不使相应技术方案的本质脱离本发明各实施例技术方案的范 围。

Claims

权 利 要 求 书
1、 一种支持多核架构下资源隔离的系统， 其特征在于， 包括： 处理器， 所述处理器包括多个处理核， 所述多个处理核中包括一个启 动时主核以及至少一个启动时从核；
内存空间，所述内存空间包括共享内存段， 以及各处理核的内存区段; 所述共享内存段中存储有运行信息， 以及各处理核的运行时入口地址； 所 述运行信息包括各处理核与各操作系统之间的对应关系、 各内存区段的大 小以及起始地址； 所述各处理核的运行时入口地址， 用于指示各处理核所 需要运行的操作系统的内核镜像文件在各自对应的内存区段中的存储地 址；
其中， 所述处理器将各处理核所需要运行的操作系统的内核镜像文件 分别存储到各处理核的内存区段中， 并将各处理核的运行时入口地址分别 写入所述共享内存段中； 待启动的处理核分别获取各自的运行时入口地 址， 并运行存储在各自的内存区段中的操作系统的内核镜像文件。
2、 根据权利要求 1 所述的支持多核架构下资源隔离的系统， 其特征 在于， 所述处理器的各处理核根据预设的选举算法在各处理核中选举确定 运行时主核； 所述运行时主核， 用于进行输入 /输出 I/O资源的仲裁控制。
3、 根据权利要求 2所述的支持多核架构下资源隔离的系统， 其特征 在于， 运行时从核将需要 I/O操作的数据放入所述共享内存段， 并将与所 述 I/O操作相关的内存地址通知所述运行时主核， 以使所述运行时主核调 用自身的本地物理驱动， 对外部设备进行所述 I/O操作。
4、 根据权利要求 2所述的支持多核架构下资源隔离的系统， 其特征 在于， 运行时从核调用自身的本地物理驱动， 对外部设备进行 I/O操作。
5、 根据权利要求 1-4任一项所述的支持多核架构下资源隔离的系统， 其特征在于， 所述启动时主核内设置有启动加载器；
所述处理器将各处理核所需要运行的操作系统的内核镜像文件分别 存储到各处理核的内存区段中， 包括：
所述启动加载器根据所述运行信息， 将各处理核所需要运行的操作系 统的内核镜像文件分别存储到各处理核的内存区段中。
6、 根据权利要求 1-4任一项所述的支持多核架构下资源隔离的系统， 其特征在于， 所述启动时主核内设置有启动加载器；
所述处理器将各处理核所需要运行的操作系统的内核镜像文件分别 存储到各处理核的内存区段中， 包括：
所述启动加载器根据所述运行信息， 在将所述处理器的至少一个处理 核的内存区段中存储所需要运行的操作系统的内核镜像文件存储到对应 的内存区段中， 运行所述操作系统的内核镜像文件； 所述运行操作系统的 处理核根据所述运行信息， 将所述处理器的需要运行操作系统的其余处理 核所对应的操作系统的内核镜像文件分别存储到各所述其余处理核对应 的内存区段中。
7、 根据权利要求 1-6任一项所述的支持多核架构下资源隔离的系统， 其特征在于， 各处理核运行互不相同的操作系统的内核镜像文件； 或者， 由至少两个处理核构成的处理核组运行相同的操作系统的内核镜像文件， 并且， 所述构成所述处理核组的所有处理核共用同一段内存区段。
8、 一种支持多核架构下资源隔离的方法， 其特征在于， 应用于包括 处理器和内存空间的支持多核架构下资源隔离的系统， 其中： 所述处理器 包括多个处理核， 所述多个处理核中包括一个启动时主核以及至少一个启 动时从核； 所述内存空间包括共享内存段， 以及各处理核的内存区段； 所 述共享内存段中存储有运行信息， 以及各处理核的运行时入口地址； 所述 运行信息包括各处理核与各操作系统之间的对应关系、 各内存区段的大小 以及起始地址； 所述各处理核的运行时入口地址， 用于指示各处理核所需 要运行的操作系统的内核镜像文件在各自的内存区段中的存储地址；
所述支持多核架构下资源隔离的方法包括：
所述处理器将各处理核所需要运行的操作系统的内核镜像文件分别 存储到各处理核的内存区段中， 并将各处理核的运行时入口地址分别写入 所述共享内存段中；
待启动的处理核分别获取各自的运行时入口地址， 并运行存储在各自 的内存区段中的操作系统的内核镜像文件。
9、 根据权利要求 8所述的支持多核架构下资源隔离的方法， 其特征 在于， 所述处理器的各处理核根据预设的选举算法在各处理核中选举确定 运行时主核； 所述运行时主核， 用于进行输入 /输出 I/O资源的仲裁控制。
10、 根据权利要求 9所述的支持多核架构下资源隔离的方法， 其特征 在于， 运行时从核将需要 I/O操作的数据放入所述共享内存段， 并将与所 述 I/O操作相关的内存地址通知所述运行时主核， 以使所述运行时主核调 用自身的本地物理驱动， 对外部设备进行所述 I/O操作。
11、 根据权利要求 9所述的支持多核架构下资源隔离的方法， 其特征 在于， 运行时从核调用自身的本地物理驱动， 对外部设备进行 I/O操作。
12、 根据权利要求 8-11 任一项所述的支持多核架构下资源隔离的方 法， 其特征在于， 所述启动时主核内设置有启动加载器；
所述处理器将各处理核所需要运行的操作系统的内核镜像文件分别 存储到各处理核的内存区段中， 包括：
所述启动加载器根据所述运行信息， 将各处理核所需要运行的操作系 统的内核镜像文件分别存储到各处理核的内存区段中。
13、 根据权利要求 8-11 任一项所述的支持多核架构下资源隔离的方 法， 其特征在于， 所述启动时主核内设置有启动加载器；
所述处理器将各处理核所需要运行的操作系统的内核镜像文件分别 存储到各处理核的内存区段中， 包括：
所述启动加载器根据所述运行信息， 在所述处理器的至少一个处理核 的内存区段中存储所需要运行的操作系统的内核镜像文件， 运行所述操作 系统的内核镜像文件； 所述运行操作系统的处理核根据所述运行信息， 将 所述处理器的需要运行操作系统的其余处理核所对应的操作系统的内核 镜像文件分别存储到各所述其余处理核的内存区段中。
14、 根据权利要求 8-13 任一项所述的支持多核架构下资源隔离的方 法， 其特征在于， 各处理核运行互不相同的操作系统的内核镜像文件； 或 者， 由至少两个处理核构成的处理核组运行相同的操作系统的内核镜像文 件， 并且， 所述构成所述处理核组的所有处理核共用同一段内存区段。
PCT/CN2013/076329 2013-05-28 2013-05-28 支持多核架构下资源隔离的方法及系统 Ceased WO2014190486A1 (zh)

Priority Applications (5)

Application Number Priority Date Filing Date Title
CN201380000917.5A CN103608792B (zh) 2013-05-28 2013-05-28 支持多核架构下资源隔离的方法及系统
JP2015559405A JP6089349B2 (ja) 2013-05-28 2013-05-28 マルチコアアーキテクチャでのリソース分離を支援するための方法およびシステム
PCT/CN2013/076329 WO2014190486A1 (zh) 2013-05-28 2013-05-28 支持多核架构下资源隔离的方法及系统
EP13885510.1A EP2851807B1 (en) 2013-05-28 2013-05-28 Method and system for supporting resource isolation under multi-core architecture
US14/573,428 US9411646B2 (en) 2013-05-28 2014-12-17 Booting secondary processors in multicore system using kernel images stored in private memory segments

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/CN2013/076329 WO2014190486A1 (zh) 2013-05-28 2013-05-28 支持多核架构下资源隔离的方法及系统

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US14/573,428 Continuation US9411646B2 (en) 2013-05-28 2014-12-17 Booting secondary processors in multicore system using kernel images stored in private memory segments

Publications (1)

Publication Number Publication Date
WO2014190486A1 true WO2014190486A1 (zh) 2014-12-04

Family

ID=50126070

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2013/076329 Ceased WO2014190486A1 (zh) 2013-05-28 2013-05-28 支持多核架构下资源隔离的方法及系统

Country Status (5)

Country Link
US (1) US9411646B2 (zh)
EP (1) EP2851807B1 (zh)
JP (1) JP6089349B2 (zh)
CN (1) CN103608792B (zh)
WO (1) WO2014190486A1 (zh)

Families Citing this family (39)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN104750510B (zh) * 2013-12-30 2019-04-02 深圳市中兴微电子技术有限公司 一种芯片启动方法及多核处理器芯片
TWI557644B (zh) * 2014-11-12 2016-11-11 鴻海精密工業股份有限公司 雙處理器電子裝置及其快速開機啓動的方法
CN106407131B (zh) * 2016-03-30 2019-06-11 沈阳泰科易科技有限公司 内存访问方法和装置
CN108228333A (zh) * 2016-12-14 2018-06-29 中国航空工业集团公司西安航空计算技术研究所 一种多核系统的核间资源隔离方法
CN108664325B (zh) * 2017-03-30 2019-06-28 视联动力信息技术股份有限公司 处理数据的方法和电子设备
US11240207B2 (en) 2017-08-11 2022-02-01 L3 Technologies, Inc. Network isolation
US11601467B2 (en) 2017-08-24 2023-03-07 L3 Technologies, Inc. Service provider advanced threat protection
US11336619B2 (en) 2017-09-28 2022-05-17 L3 Technologies, Inc. Host process and memory separation
US11374906B2 (en) 2017-09-28 2022-06-28 L3 Technologies, Inc. Data exfiltration system and methods
US11223601B2 (en) * 2017-09-28 2022-01-11 L3 Technologies, Inc. Network isolation for collaboration software
US11552987B2 (en) 2017-09-28 2023-01-10 L3 Technologies, Inc. Systems and methods for command and control protection
US10831626B2 (en) 2017-10-19 2020-11-10 International Business Machines Corporation Method to sort partially good cores for specific operating system usage
US11550898B2 (en) 2017-10-23 2023-01-10 L3 Technologies, Inc. Browser application implementing sandbox based internet isolation
US10824584B1 (en) * 2018-04-03 2020-11-03 Xilinx, Inc. Device with data processing engine array that enables partial reconfiguration
US10642657B2 (en) * 2018-06-27 2020-05-05 The Hong Kong Polytechnic University Client-server architecture for multicore computer system to realize single-core-equivalent view
CN109413497B (zh) * 2018-09-12 2021-04-13 海信视像科技股份有限公司 一种智能电视机及其系统启动方法
KR102558901B1 (ko) 2018-09-19 2023-07-25 에스케이하이닉스 주식회사 메모리 시스템 및 메모리 시스템의 동작방법
CN111767082A (zh) * 2019-04-02 2020-10-13 华为技术有限公司 计算芯片启动方法、装置和计算机系统
CN110471705A (zh) * 2019-07-15 2019-11-19 江苏泛腾电子科技有限公司 一种定制双系统
CN110704116A (zh) * 2019-09-17 2020-01-17 一汽解放汽车有限公司 基于嵌入式处理器的一机多屏系统的实现方法
CA3158104A1 (en) * 2019-11-25 2021-06-03 Mircea Orban Automated lifecycle management flexible scaling and dynamic resource allocation for virtualized cable data plane applications
CN111240751B (zh) * 2019-12-27 2024-06-07 深圳市众鸿科技股份有限公司 一种基于车载智能座舱的硬件隔离方法及系统
CN111475213B (zh) * 2020-04-03 2023-04-28 深圳忆联信息系统有限公司 多核结构固态硬盘的功耗降低方法、装置和计算机设备
DE102020205146A1 (de) * 2020-04-23 2021-10-28 Robert Bosch Gesellschaft mit beschränkter Haftung Vorrichtung und Verfahren zur Steuerung eines technischen Systems
CN114064128B (zh) * 2020-07-29 2024-01-02 华为技术有限公司 内核重启方法
CN111966410B (zh) * 2020-07-31 2023-11-14 龙芯中科技术股份有限公司 启动处理方法、装置、电子设备及存储介质
US11755223B2 (en) * 2020-09-29 2023-09-12 EMC IP Holding Company LLC Systems for modular hybrid storage devices
US11586508B2 (en) 2020-09-29 2023-02-21 EMC IP Holding Company LLC Systems and methods for backing up volatile storage devices
US11550506B2 (en) 2020-09-29 2023-01-10 EMC IP Holding Company LLC Systems and methods for accessing hybrid storage devices
CN113094111B (zh) * 2021-04-16 2024-01-09 三星（中国）半导体有限公司 设备以及设备的启动方法
CN115221073A (zh) * 2021-04-21 2022-10-21 华为云计算技术有限公司 用于运行云业务实例的物理服务器的内存管理方法和装置
CN113407247A (zh) * 2021-07-16 2021-09-17 上海金脉电子科技有限公司 基于多核处理器的双系统启动方法
TWI841882B (zh) 2021-11-25 2024-05-11 緯穎科技服務股份有限公司 系統開機方法及其相關電腦系統
CN114281344B (zh) * 2021-12-30 2025-10-21 成都乐创自动化技术股份有限公司 一种嵌入式设备多核多操作系统同时运行的方法
CN115495159A (zh) * 2022-11-14 2022-12-20 南京芯驰半导体科技有限公司 芯片多硬件域启动方法及装置
CN115794680B (zh) * 2022-11-29 2026-03-27 普华基础软件股份有限公司 一种基于硬件克隆技术的多核操作系统及其控制方法
TWI864641B (zh) * 2023-03-21 2024-12-01 瑞昱半導體股份有限公司 多叢集系統以及多叢集系統控制方法
US20250355757A1 (en) * 2024-05-17 2025-11-20 Nvidia Corporation Identifying thread errors
CN119946161B (zh) * 2025-04-07 2025-06-17 南京理工大学 面向保护测量与控制的多业务强实时响应软件部署方法、系统及设备

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101149728A (zh) * 2007-10-29 2008-03-26 中国科学院计算技术研究所 一种多核处理系统及其管理方法
CN102541805A (zh) * 2010-12-09 2012-07-04 沈阳高精数控技术有限公司 一种基于共享内存的多处理器通信方法及其实现装置
CN103020002A (zh) * 2012-11-27 2013-04-03 中国人民解放军信息工程大学 可重构多处理器系统
CN103092788A (zh) * 2012-12-24 2013-05-08 华为技术有限公司 多核处理器及数据访问方法

Family Cites Families (27)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2753706B2 (ja) * 1987-12-09 1998-05-20 富士通株式会社 計算機におけるｉｐｌ方法
JPH06295289A (ja) * 1993-04-09 1994-10-21 Hitachi Ltd 複数計算機におけるブート方法
US5590301A (en) * 1995-10-06 1996-12-31 Bull Hn Information Systems Inc. Address transformation in a cluster computer system
CA2382929A1 (en) * 1999-08-31 2001-03-08 Times N Systems, Inc. Shared memory disk
US6754788B2 (en) * 2001-03-15 2004-06-22 International Business Machines Corporation Apparatus, method and computer program product for privatizing operating system data
US7007161B2 (en) * 2002-01-08 2006-02-28 Agile Tv Corporation Fast booting of plex array
US7386711B1 (en) * 2002-01-08 2008-06-10 Cisco Technology, Inc. Method and apparatus for redirecting the boot operations of one or more systems
US7363484B2 (en) * 2003-09-15 2008-04-22 Hewlett-Packard Development Company, L.P. Apparatus and method for selectively mapping proper boot image to processors of heterogeneous computer systems
US7523157B2 (en) * 2003-09-25 2009-04-21 International Business Machines Corporation Managing a plurality of processors as devices
US7581229B2 (en) * 2005-03-11 2009-08-25 Microsoft Corporation Systems and methods for supporting device access from multiple operating systems
US20080046705A1 (en) * 2006-08-15 2008-02-21 Tyan Computer Corporation System and Method for Flexible SMP Configuration
US7908470B1 (en) * 2006-10-31 2011-03-15 Hewlett-Packard Development Company, L.P. Multi-processor computer with plural boot memories
US20080109624A1 (en) * 2006-11-03 2008-05-08 Gilbert Jeffrey D Multiprocessor system with private memory sections
US7836293B1 (en) * 2007-05-07 2010-11-16 Force 10 Networks, Inc Accelerated deserialized boot implementation for a multiprocessor system
US8015383B2 (en) * 2007-06-27 2011-09-06 International Business Machines Corporation System, method and program to manage virtual memory allocated by a virtual machine control program
EP2195741A4 (en) * 2007-10-04 2011-01-05 Openpeak Inc FIRMWARE IMAGE UPDATE AND ADMINISTRATION
CN101256512B (zh) * 2008-03-20 2011-06-22 中兴通讯股份有限公司 异构多核体系中主引导核的自动选举方法
JP5328410B2 (ja) * 2009-02-20 2013-10-30 三菱電機株式会社 被起動オペレーティングシステム（ｏｓ）動作計算機、計算機のｏｓ起動方法およびｏｓ起動プログラム
WO2010097925A1 (ja) * 2009-02-26 2010-09-02 株式会社日立製作所 情報処理装置
KR20110013867A (ko) * 2009-08-04 2011-02-10 삼성전자주식회사 메모리 링크 아키텍쳐에서 플래시 레스 부팅 기능을 갖는 멀티 프로세서 시스템
CN102576312A (zh) * 2009-10-01 2012-07-11 三菱电机株式会社 计算机装置
US9058191B2 (en) * 2010-03-22 2015-06-16 Qualcomm Incorporated Direct transfer of executable software image to memory allocated by target processor based on transferred image header
US8838949B2 (en) * 2010-03-22 2014-09-16 Qualcomm Incorporated Direct scatter loading of executable software image from a primary processor to one or more secondary processor in a multi-processor system
KR20120092222A (ko) * 2011-02-11 2012-08-21 삼성전자주식회사 보안 부팅 방법 및 보안 부트 이미지 생성 방법
US8954721B2 (en) * 2011-12-08 2015-02-10 International Business Machines Corporation Multi-chip initialization using a parallel firmware boot process
JP5756144B2 (ja) * 2013-04-22 2015-07-29 レノボ・シンガポール・プライベート・リミテッド オペレーティング・システムの管理方法、コンピュータ・プログラムおよびコンピュータ
US9880888B2 (en) * 2013-06-07 2018-01-30 Mitsubishi Electric Corporation Executing an operating system in a multiprocessor computer system

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101149728A (zh) * 2007-10-29 2008-03-26 中国科学院计算技术研究所 一种多核处理系统及其管理方法
CN102541805A (zh) * 2010-12-09 2012-07-04 沈阳高精数控技术有限公司 一种基于共享内存的多处理器通信方法及其实现装置
CN103020002A (zh) * 2012-11-27 2013-04-03 中国人民解放军信息工程大学 可重构多处理器系统
CN103092788A (zh) * 2012-12-24 2013-05-08 华为技术有限公司 多核处理器及数据访问方法

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See also references of EP2851807A4 *

Also Published As

Publication number Publication date
EP2851807A4 (en) 2015-04-22
CN103608792A (zh) 2014-02-26
US9411646B2 (en) 2016-08-09
JP2016508647A (ja) 2016-03-22
CN103608792B (zh) 2016-03-09
JP6089349B2 (ja) 2017-03-08
US20150106822A1 (en) 2015-04-16
EP2851807A1 (en) 2015-03-25
EP2851807B1 (en) 2017-09-20

Similar Documents

Publication Publication Date Title
WO2014190486A1 (zh) 支持多核架构下资源隔离的方法及系统
JP2016508647A5 (zh)
JP7813305B2 (ja) オペレーティングシステムの実行制御方法、装置、組み込みシステム及びチップ
US9912535B2 (en) System and method of performing high availability configuration and validation of virtual desktop infrastructure (VDI)
CN105393212B (zh) 使用锁定机制进行高效任务调度的方法、系统和存储介质
JP6868087B2 (ja) 管理コントローラへの通信チャネルの方法及びシステム
EP3803663B1 (en) Watchdog timer hierarchy
US11888690B2 (en) System and method for subscription limitation enforcement in distributed system
CN115151902B (zh) 集群扩容方法、装置、存储介质及电子设备
JP6123626B2 (ja) 処理再開方法、処理再開プログラムおよび情報処理システム
WO2016106756A1 (zh) 一种容灾方法、系统和装置
US8185913B1 (en) Manageability platform in an unified system
CN114115703A (zh) 裸金属服务器在线迁移方法以及系统
WO2026066507A1 (zh) 服务器设备的启动方法及装置
WO2015167453A1 (en) Computing system management using shared memory
JP4692912B2 (ja) リソース割り当てシステム、及びリソース割り当て方法
US8799903B1 (en) Systems and methods for exchanging runtime functionalities between software stacks
US20240004563A1 (en) Performance Efficient and Resilient Creation of Network Attached Storage Obects
CN105765546B (zh) 使用隔绝的分区的弹性虚拟多路径资源访问
CN111694787A (zh) 一种芯片启动的方法、网络设备和机器可读存储介质
JP5994690B2 (ja) 情報処理装置、プログラムおよび記憶領域獲得方法
CN102662702B (zh) 设备管理系统、装置、基板管理装置及方法
TW201837731A (zh) 儲存實體資源的本地磁碟抹除機制
CN117369981A (zh) 基于监控器的容器调整方法、设备及存储介质
JP2012003510A (ja) 計算機及び転送プログラム

Legal Events

Date Code Title Description
WWE Wipo information: entry into national phase

Ref document number: 201380000917.5

Country of ref document: CN

REEP Request for entry into the european phase

Ref document number: 2013885510

Country of ref document: EP

WWE Wipo information: entry into national phase

Ref document number: 2013885510

Country of ref document: EP

121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 13885510

Country of ref document: EP

Kind code of ref document: A1

ENP Entry into the national phase

Ref document number: 2015559405

Country of ref document: JP

Kind code of ref document: A

NENP Non-entry into the national phase

Ref country code: DE