WO2017082505A1 - 멀티 운영시스템을 지닌 전자장치 및 이의 동적 메모리 관리 방법 - Google Patents

멀티 운영시스템을 지닌 전자장치 및 이의 동적 메모리 관리 방법 Download PDF

Info

Publication number
WO2017082505A1
WO2017082505A1 PCT/KR2016/006570 KR2016006570W WO2017082505A1 WO 2017082505 A1 WO2017082505 A1 WO 2017082505A1 KR 2016006570 W KR2016006570 W KR 2016006570W WO 2017082505 A1 WO2017082505 A1 WO 2017082505A1
Authority
WO
WIPO (PCT)
Prior art keywords
memory
operating system
available
module
request
Prior art date
Application number
PCT/KR2016/006570
Other languages
English (en)
French (fr)
Inventor
정복득
이성민
Original Assignee
삼성전자 주식회사
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 삼성전자 주식회사 filed Critical 삼성전자 주식회사
Priority to US15/774,356 priority Critical patent/US10817332B2/en
Publication of WO2017082505A1 publication Critical patent/WO2017082505A1/ko

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR 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/48—Program initiating; Program switching, e.g. by interrupt
    • G06F9/4806—Task transfer initiation or dispatching
    • G06F9/4843—Task transfer initiation or dispatching by program, e.g. task dispatcher, supervisor, operating system
    • G06F9/485—Task life-cycle, e.g. stopping, restarting, resuming execution
    • G06F9/4856—Task life-cycle, e.g. stopping, restarting, resuming execution resumption being on a different machine, e.g. task migration, virtual machine migration
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR 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/54—Interprogram communication
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/30—Monitoring
    • G06F11/3003—Monitoring arrangements specially adapted to the computing system or computing system component being monitored
    • G06F11/3037—Monitoring arrangements specially adapted to the computing system or computing system component being monitored where the computing system component is a memory, e.g. virtual memory, cache
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/30—Monitoring
    • G06F11/3055—Monitoring arrangements for monitoring the status of the computing system or of the computing system component, e.g. monitoring if the computing system is on, off, available, not available
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F12/00—Accessing, addressing or allocating within memory systems or architectures
    • G06F12/02—Addressing or allocation; Relocation
    • G06F12/0223—User address space allocation, e.g. contiguous or non contiguous base addressing
    • G06F12/0284—Multiple user address space allocation, e.g. using different base addresses
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR 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/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR 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/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533—Hypervisors; Virtual machine monitors
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR 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/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533—Hypervisors; Virtual machine monitors
    • G06F9/45545—Guest-host, i.e. hypervisor is an application program itself, e.g. VirtualBox
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR 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/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533—Hypervisors; Virtual machine monitors
    • G06F9/45558—Hypervisor-specific management and integration aspects
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR 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
    • G06F9/5011—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resources being hardware resources other than CPUs, Servers and Terminals
    • G06F9/5016—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resources being hardware resources other than CPUs, Servers and Terminals the resource being the memory
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR 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/5061—Partitioning or combining of resources
    • G06F9/5077—Logical partitioning of resources; Management or configuration of virtualized resources
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/30—Monitoring
    • G06F11/34—Recording or statistical evaluation of computer activity, e.g. of down time, of input/output operation ; Recording or statistical evaluation of user activity, e.g. usability assessment
    • G06F11/3409—Recording or statistical evaluation of computer activity, e.g. of down time, of input/output operation ; Recording or statistical evaluation of user activity, e.g. usability assessment for performance assessment
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F12/00—Accessing, addressing or allocating within memory systems or architectures
    • G06F12/02—Addressing or allocation; Relocation
    • G06F12/0223—User address space allocation, e.g. contiguous or non contiguous base addressing
    • G06F12/023—Free address space management
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F12/00—Accessing, addressing or allocating within memory systems or architectures
    • G06F12/02—Addressing or allocation; Relocation
    • G06F12/08—Addressing or allocation; Relocation in hierarchically structured memory systems, e.g. virtual memory systems
    • G06F12/10—Address translation
    • G06F12/109—Address translation for multiple virtual address spaces, e.g. segmentation
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR 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/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533—Hypervisors; Virtual machine monitors
    • G06F9/45558—Hypervisor-specific management and integration aspects
    • G06F2009/4557—Distribution of virtual machine instances; Migration and load balancing
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR 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/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533—Hypervisors; Virtual machine monitors
    • G06F9/45558—Hypervisor-specific management and integration aspects
    • G06F2009/45583—Memory management, e.g. access or allocation
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2212/00—Indexing scheme relating to accessing, addressing or allocation within memory systems or architectures
    • G06F2212/10—Providing a specific technical effect
    • G06F2212/1016—Performance improvement
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2212/00—Indexing scheme relating to accessing, addressing or allocation within memory systems or architectures
    • G06F2212/15—Use in a specific computing environment
    • G06F2212/151—Emulated environment, e.g. virtual machine
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2212/00—Indexing scheme relating to accessing, addressing or allocation within memory systems or architectures
    • G06F2212/15—Use in a specific computing environment
    • G06F2212/152—Virtualized environment, e.g. logically partitioned system
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2212/00—Indexing scheme relating to accessing, addressing or allocation within memory systems or architectures
    • G06F2212/50—Control mechanisms for virtual memory, cache or TLB
    • G06F2212/502—Control mechanisms for virtual memory, cache or TLB using adaptive policy
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2212/00—Indexing scheme relating to accessing, addressing or allocation within memory systems or architectures
    • G06F2212/65—Details of virtual memory and virtual address translation
    • G06F2212/657—Virtual address space management

Definitions

  • the present disclosure relates to an electronic device having multiple operating systems, and more particularly, to the performance of each operating system in a virtualized computing system having a host operating system and a plurality of guest operating systems.
  • Virtualization technology abstracts the physical devices to provide a separate execution environment.
  • a guest operating system that operates on a host operating system and a virtual machine in the host operating system environment. System can run as if it were a separate operating system.
  • the guest OS operating in the virtual machine shares and distributes the CPU, memory, and storage space of the host OS and the electronic device with each other.
  • the importance of the application is given in the order of the function of the application and the latest execution order.
  • the available memory of the host OS is insufficient, applications with high memory usage and low priority are killed. Therefore, since the guest OS of the virtual machine running in the form of an application of the host OS has a high memory usage, there is a high possibility of killing when the host OS runs out of memory. In other words, the guest OS may unexpectedly terminate abnormally.
  • a host operating system and a guest operating system need a technology for managing limited resources and memory to improve performance of each operating system.
  • the present disclosure is directed to improving the performance of each operating system in an electronic device having a virtualized computing system having a host operating system and a plurality of guest operating systems. It is an object of the present invention to provide a method for managing dynamic memory of an electronic device and an electronic device having the method.
  • an electronic device on which an operating system (OS) is executed includes the first OS according to available memory conditions of a first OS and a second OS.
  • a first memory management module which directly determines to transfer the memory of the memory to the second OS and to recover the transferred memory, and requests the second OS to execute the transfer and recovery;
  • the first state collecting module collecting memory availability state information of the first OS and requesting the second OS to collect memory information of the second OS at a designated collection interval;
  • a memory allocation module for allocating the dynamic memory of the first OS by the second OS according to a request of the first OS;
  • a second state collection module that collects memory availability state information of the second OS ;
  • a second memory management module configured to manage the memory of the second OS by receiving the memory of the first OS or returning the received memory to the first memory based on the dynamic memory allocation information.
  • the first OS memory management module determines available memory state information of the first OS and the second OS, when the second OS is executed as a main and the first OS is executed as a sub. Request delivery of the available memory of the OS to the memory allocation module for use by the second OS, and when the first OS is executed as the main, the first OS may request the memory allocation module to retrieve the transferred memory. .
  • the first memory management module transfers a memory from the first OS to the second OS and determines a minimum available memory amount according to the determined available memory condition, and determines the determined available memory condition and the minimum available memory. Based on the amount, one of a request for transferring and retrieving the memory of the first OS to the second OS may be determined.
  • the minimum available memory amount may be designated by the first OS as a minimum amount of available memory for executing an application of the first OS, and according to the designated available memory amount, the first OS may be assigned to the second OS.
  • a memory reclamation request may be requested, and the designated available memory amount may be determined according to an average usage amount of the application.
  • the determination of the transfer or retrieval may determine whether the first OS transfers or retrieves the memory to the second OS, and may request the memory allocation module of the second OS according to a determination result.
  • the first OS may be a plurality of first OSs, and the plurality of first OSs may include a first memory management module installed in each of the first OSs to transfer the memory of the first OS to the second OS through distributed computing. Alternatively, it may be determined whether to recover to the first OS.
  • the collection period may be determined according to whether the first OS and the second OS are in proximity to a memory shortage state and whether the memory usage is changed, and the first OS is a memory shortage event of the first OS and the second OS.
  • the first memory management module may be executed without waiting for the designated collection period.
  • the memory allocation module allocates the memory of the first OS to the second OS or executes the recovery of the allocated memory to the first OS according to a request of the first OS.
  • the memory of the first OS may be allocated to another first OS.
  • the second memory state collection module when a state change of the second OS occurs, collects memory availability state information of the second OS, and requests the information to the first OS when the information of the first OS is requested. Or when the second OS memory is insufficient, the low memory state of the second OS may be transmitted to the first OS.
  • the first OS is a guest operating system
  • the first memory management module and the first state collection module are executed in the guest operating system of a virtual machine
  • the second OS is a host operating system
  • the second memory The management module, the memory allocation module, and the second state collection module may be executed in the host operating system.
  • a dynamic memory management method between a first OS and a second OS in an electronic device on which an operating system (OS) is executed may include: A first memory management step of directly determining to transfer the memory of the first OS to the second OS and recovering the transferred memory according to an available memory situation, and requesting the second OS to execute the transfer and recovery; A first state collecting step of collecting memory availability state information of the first OS and requesting the second OS to collect memory information of the second OS at a specified collection period; A memory allocation step of the second OS allocating a dynamic memory of the first OS according to a request of the first OS; A second state collecting step of collecting memory availability state information of the second OS ; And a second memory management step of managing the memory of the second OS by receiving the memory of the first OS or returning the received memory to the first memory based on the dynamic memory allocation information.
  • the first memory management step includes determining available memory state information of the first OS and the second OS, when the second OS is executed as a main and the first OS is executed as a sub. A request is made to transfer the available memory of the memory allocation module to the second OS for use, and when the first OS is executed as the main, the first OS may request the memory allocation module to retrieve the transferred memory.
  • the managing of the first memory may include transferring a memory from the first OS to the second OS and determining a minimum available memory amount according to the determined available memory condition, and determining the determined available memory condition and the minimum memory unit. Based on this, one of a request for transferring and retrieving the memory of the first OS to the second OS may be determined.
  • the minimum available memory amount may be designated by the first OS as a minimum amount of available memory for executing an application of the first OS, and according to the designated available memory amount, the first OS may be configured as the second OS.
  • a memory reclamation request may be made, and the designated available memory amount may be determined according to an average usage amount of the application.
  • the determination of the transfer or retrieval may determine whether the first OS transfers or retrieves the memory to the second OS, and may request the memory allocation module of the second OS according to a determination result.
  • the first OS may be a plurality of first OSs, and the plurality of first OSs may be configured to transfer or retrieve memory of the first OS to the second OS by distributed computing by a first memory management module installed in each of the first OSs. You can decide whether or not.
  • the collection period may be determined according to whether the first OS and the second OS are close to a memory shortage state and whether the memory usage is changed, and the first OS is an insufficient memory event of the first OS and the second OS.
  • the memory management module may be executed without waiting for the set collection period.
  • the memory allocation module allocates the memory of the first OS to the second OS or allocates the memory to execute a recovery to the first OS according to a request of the first OS.
  • the memory of the first OS may be allocated to another first OS.
  • the second memory state collection module when a state change of the second OS occurs, collects memory availability state information of the second OS, and requests the information to the first OS when the information of the first OS is requested. Or when the second OS memory is insufficient, the low memory state of the second OS may be transmitted to the first OS.
  • the first OS is a guest operating system
  • the first memory management module and the first state collection module are executed in a guest operating system of a virtual machine
  • the second OS is a host operating system
  • the second memory The management module, the memory allocation module, and the second state collection module may be executed in a host operating system.
  • the guest OS collects available memory state information of the guest OS and the host OS, and the memory is not used by the guest OS. It can be delivered to the host OS, and when the memory of the guest OS is insufficient, the memory delivered to the host OS can be recovered, thereby preventing performance degradation due to insufficient memory of the host OS and the guest OS.
  • first OS guest operating system
  • second OS host operating system
  • FIG. 2 is a general block diagram of a virtualized computing system, in accordance with an embodiment of the present disclosure
  • FIG. 3 is a block diagram of a first operating system and a second operating system, in accordance with an embodiment of the present disclosure
  • FIG. 4 illustrates dynamic memory management when the first operating system is running main, according to one embodiment of the present disclosure
  • FIG. 5 illustrates dynamic memory management when the first operating system is running as a sub, according to one embodiment of the present disclosure
  • FIG. 6 is a flowchart illustrating dynamic memory management according to an embodiment of the present disclosure
  • FIG. 7A and 7B illustrate memory transfer and retrieval request frequencies according to a minimum memory unit for requesting a transfer and retrieval of memory from a first OS to a second OS in the prior art and the disclosure, according to an embodiment of the present disclosure.
  • FIG. 8 is a simple block diagram of an electronic device according to an embodiment of the present disclosure.
  • first and second may be used to describe various components, but the components should not be limited by the terms. The terms are used only for the purpose of distinguishing one component from another.
  • first component may be referred to as the second component, and similarly the second component may also be referred to as the first component.
  • FIG. 1 is an illustration of an electronic device 100 having a host operating system 101 and a guest operating system 102 having a plurality of applications 103-n in accordance with one embodiment of the present disclosure.
  • the host operating system 101 may be a second operating system (second OS)
  • the guest operating system 102 may be a first operating system (first OS).
  • the host operating system 101 and the guest operating system 102 can execute various data and applications within each operating system.
  • the guest operating system 102 can be an operating system operating within a virtual machine.
  • the host operating system 101 and the guest operating system 102 may share a CPU (not shown), a memory (not shown), and a storage space (not shown) of the electronic device 100.
  • guest operating system 102 may deliver memory to host operating system 101 that is not in use by guest operating system 102.
  • the guest operating system 102 may request to retrieve the memory delivered to the host operating system 101 and return it.
  • the electronic device 100 may simultaneously have a host operating system 101 and a guest operating system 102.
  • the electronic device 100 may have one host operating system 101 and a plurality of guest operating systems 102-n (not shown).
  • an application executed by the guest operating system 102 when an application executed by the guest operating system 102 is selected by a user, applications operating in the guest operating system 102 are executed on the main display of the electronic device 100, An application executed by the host operating system 101 may operate or stop an operation of a sub screen of the electronic device 100. That is, the electronic device 100 may execute the selected application through the operating system selected by the user.
  • the electronic device 100 may be a mobile device such as a smartphone, a tablet PC, and a smart car.
  • the host operating system 101 and the guest operating system 102 may be various operating systems such as a mobile platform.
  • the plurality of applications 103-n may be applications provided by the guest operating system 102.
  • FIG. 2 is a general block diagram of a virtualized computing system, in accordance with an embodiment of the present disclosure.
  • Virtualized computing environments are divided into "type 1" and "type 2" depending on the location of the hypervisor.
  • the electronic device 100 may apply a “type 2” virtual computing environment among virtualization technologies.
  • a virtual computing environment employing a “type 2” virtualization technology is hardware (not shown) including a central processing unit (CPU) (not shown), memory (not shown), input / output device (not shown), and the like at the lowest level. ) Is located.
  • CPU central processing unit
  • memory not shown
  • input / output device not shown
  • the host operating system 200 is positioned on the hardware (not shown), and the hypervisor 230 or the virtual machine monitor (not shown) is positioned on the host operating system 200.
  • the hypervisor 230 may provide an environment in which the new operating system, the guest operating system 270, may be independently executed through the virtual machine 250.
  • an application (not shown) running on the host operating system 210 and an application 290 running on the guest operating system 270 are executed in virtually different physical spaces. To provide.
  • the guest operating system 270 may operate in a plurality. That is, N guest operating systems 270n corresponding to each virtual machine 250n may be located on the N virtual machines 250n. In addition, the M applications 290m corresponding to each guest operating system 270n may operate in the N guest operating systems 270n.
  • FIG. 3 is a block diagram of a first operating system and a second operating system, in accordance with an embodiment of the present disclosure.
  • the first operating system may be a guest OS 102 and the second operating system may be a host OS 101.
  • Guest OS 102 can operate in a virtual machine (not shown).
  • the first state collection module 310 and the first memory management module 330 are user-level loaded in a virtual machine (not shown). application).
  • the first state collection module 310 may collect memory available state information of the first OS 102.
  • the memory availability status information may be a total memory specified in the first OS 102.
  • the memory availability status information may be a free memory in which the first OS 102 executes applications operating in the first OS 102 among the designated total memory.
  • the memory availability status information may be available memory size that the first OS 102 can transfer to the second OS 102.
  • the first state collection module 310 may request the second state collection module 350 of the second OS 101 to collect memory information of the second OS 101 in a specified collection cycle.
  • the information collected by the first state collection module 310 may be transferred to the first memory management module 330.
  • the first state collection module 310 when performing the memory information collection of the second OS 101, the first state collection module 310 may be performed through virtual memory information register access to minimize overhead. have.
  • the first state collection module 310 may determine whether the memory pressure of the first OS 102 and the second OS 101 is close and whether the memory usage of each OS 102 or 101 changes. A period for collecting memory state information of the first OS 102 and the second OS 101 may be specified. In this case, the first OS 102 may transmit the memory to the second OS 101 based on the memory state information of the first OS 102 and the second OS 101. The memory transferred to the second OS 101 may be requested to be recovered.
  • the amount of memory transferred from the designated total memory of the first OS 102 to the second operating system 101 is greater than or equal to the specified threshold of the designated total memory of the first OS 102.
  • the collection period may be varied according to the variation amount of the remaining memory of the first OS 102.
  • the first OS 102 may be assigned 1 GB of total memory. That is, when the user selects to execute the first OS 102 in the electronic device 100, the first OS 102 is allocated with a size of 1 GB so that the first OS 102 can be executed within the 1 GB memory limit. Memory can be specified.
  • the first OS 102 when the electronic device 100 is a smartphone, when the user selects the first application 103-1 of the first OS 102 on the electronic device 100, the first OS 102 The designated 1 GB to 200 MB may be allocated to run the first application 103-1. In addition, when the user selects the fourth application 103-4, the first OS 102 may allocate 200 MB to execute the fourth application 103-4. In this case, the first OS 102 may use 400 MB of memory of 1 GB and transfer the memory to the second OS 101 according to a memory shortage state of the second OS 101 of the remaining 600 MB.
  • the amount of memory being used by the first OS 102 to execute the n-th application 103-n and the amount of memory transferred by the first OS 102 to the second OS 101 is determined by the first OS 102.
  • the specified memory (total memory) of 1GB exceeds the specified threshold of 650MB (65% of the total memory)
  • the first state collection module 310 to the second state collection module 350 The memory state information of the OS 101 may be requested.
  • the first state collection module 310 is reset every two seconds. 2 may request memory status information from the OS 101. That is, if more than 95% (617MB) of 650MB (65%), which is a threshold value designated as the memory size for executing the first OS 102, is used among 1 GB of designated memory of the first OS 102, Since the memory margin for running the OS 102 may be insufficient, status information may be requested to the host OS 101 at frequent intervals.
  • the first state collection module 310 is used. ) May request memory status information from the second OS 101 at intervals of 4 seconds. That is, 80% to 95% (520MB to 617MB) of 650MB (65%), which is a threshold value designated as the memory size for executing the first OS 102, among the 1GB of the designated memory of the first OS 102 is in use. As the memory usage of the first OS 102 decreases, the collection period may be increased by adding the collection period by 4 seconds to 4 seconds (4 + x).
  • the first state collection module 310 may perform the 10 second cycle.
  • Memory status information may be requested to the second OS 101. That is, if 1 GB of the specified memory of the first OS 102 is being used below 80% (520 MB) of 650 MB (65%), which is a threshold value specified as the memory size for executing the first OS 102, Since there is a large amount of memory in the OS 102, the collection period may be increased by adding 10 seconds to 10 seconds as the memory usage of the first OS 102 decreases (10 + x).
  • the collection period illustrated above is only one embodiment to describe the present disclosure, and the designated memory of the guest OS 102 may be implemented differently according to the guest OS 102.
  • a threshold for the designated memory of the guest OS 102 and a corresponding period setting may also be variously implemented according to the memory usage and the amount of memory variation of the guest OS 102.
  • the first memory management module 330 may be executed in a kernel (not shown) in the guest operating system 102. However, this is only one embodiment for the present disclosure. When the electronic device 100 is a desktop computer, the first memory management module 330 may be a driver (not shown) of the guest operating system 102.
  • the first memory management module 330 stores the memory of the first OS 102 according to the available memory conditions of the first OS 102 and the second OS 101 collected by the first state collection module. It may be determined that the data is delivered to the device 101, and the memory delivered to the second OS 101 may be determined to be recovered to the first OS 102 again. In this case, the first memory management module 330 requests the memory allocation module 370 to determine the determined memory transfer and retrieval, and the memory allocation module 370 manages the first memory in the second memory management module 390. Deliver the request received from module 330. When a memory shortage event occurs in the second OS 101, the first memory management module 330 directly passes through the second memory management module 390 without passing through the memory allocation module 370. May be transferred to the second OS 101. In addition, when the memory shortage event occurs in the first OS 102, the first memory management module 330 immediately transfers the memory delivered by the first OS 102 to the second OS 101 to the memory allocation module 370. You can request a recovery.
  • the first memory management module 330 requests the memory allocation module 370 when the first OS 102 is being executed in the electronic device 100 as the main, so that the first OS 102 receives the second OS.
  • the memory transferred to 101 can be recovered.
  • the first memory management module 330 makes a request for recovery to return the memory transferred from the second OS 101
  • the second OS 101 is in the second OS 101 due to the extreme memory shortage. You can prevent key running services from being killed. That is, the memory may be implemented to receive the memory from the second OS 101 in consideration of the designated minimum available memory and the designated threshold memory of the first OS 102.
  • the electronic device 100 when the electronic device 100 is a smartphone, when the user selects the first OS 102 on the screen of the smartphone 100, the first OS 102, which is a guest OS, is used. ) May be executed as the main in front of the screen of the smartphone 100 having an interaction with the current user.
  • the second OS 101 may be at the back of the screen which does not have interaction with the current user.
  • the first OS 102 may request a recovery to return the memory of the first OS 102 that has been transmitted to the second OS 101.
  • the first memory management module of the first OS 102 may perform main services (for example, running in the second OS 101).
  • the call function, the alarm functions) may be implemented to control the amount of memory to be recovered from the second OS 101 so as not to be killed.
  • the first memory management module 330 requests the memory allocation module 370 when the second OS 101 is executed as the main in the electronic device 100 and the first OS 102 is executed as the sub.
  • the memory of the first OS 102 may be transferred to the second OS 101.
  • the host OS when the electronic device 100 is a smartphone, when the user selects an application operating in the second OS 101 on the screen of the smartphone 100, the host OS may be a host OS.
  • the second OS 101 may be executed as the main in front of the screen of the smartphone 100 having an interaction with the current user.
  • the first OS 102 may be at the back of the screen that does not have interaction with the current user.
  • the first OS 102 may transfer the available memory of the first OS 102 to the second OS 101 as much as possible.
  • the first OS 102 reaches the minimum amount of available memory that can be executed, the first OS 102 can request to return the memory that has been delivered to the second OS 101.
  • the first memory management module 330 may determine whether or not the first OS 102 or the second OS 101 collects available memory state information based on the available memory state information of the first OS 102 and the second OS 101.
  • the minimum amount of available memory may be determined for transferring the memory to the second OS 101 and reclaiming the memory to the first OS 102 again.
  • the minimum amount of available memory is a minimum unit of available memory for executing applications of the first OS 102 and may be determined according to an average memory usage of the application. In this case, the minimum available memory may be previously designated by the first OS 102.
  • the first OS 102 may be allocated 1 GB of designated memory.
  • 650 MB which is 65% of the 1 GB of memory specified in the first OS 102, may be designated as a threshold.
  • the minimum available memory amount for reclaiming the memory transferred by the first OS 102 to the second OS 101 can be designated as 64 MB.
  • the first OS 102 may not request the recovery of the memory transferred to the second OS 101 until 64 MB of the 1 GB remains. Accordingly, the frequency of requesting memory transfer and retrieval to the memory allocation module 370 of the second OS 101 is reduced, thereby reducing power usage, and the second OS 101 can execute an application in a stable memory state.
  • the first memory management module 330 requests the memory recovery request from the second OS 101 based on the threshold value 650MB specified by the first state collection module 310. can do.
  • the second OS 101 which is a host OS, uses a large amount of memory to execute an application
  • the second OS 101 may frequently exceed the threshold of 650 MB.
  • the first OS 102 may frequently request a memory retrieval request from the memory allocation module 370 of the second OS 101.
  • the above-described examples are merely one embodiment of the present invention for explaining the minimum available memory setting of the first memory management module 330, and the present disclosure is an application 103-n memory average of the guest OS 102. It can be implemented in various ways depending on the usage.
  • the first memory management module 330 designates the minimum available memory for requesting to recover the memory delivered by the first OS 102 to the second OS 101, thereby allowing the first memory management module 330 to display the second memory.
  • the frequency of recognizing the memory shortage of the OS 101 can be reduced.
  • the frequency of requesting the number of times of memory request from the second OS 101 can be reduced. Therefore, the second OS 101 can receive the insufficient memory from the first OS 102 and stably execute the application, and can reduce the power consumption by reducing the frequency of requests.
  • the second state collection module 350 may be executed in the kernel (not shown) memory management system of the host operating system 101 and may be executed at the user level of the host operating system 101. However, this is only one embodiment for the present disclosure. When the electronic device 100 is a desktop computer, the second state collection module 350 may be executed by a driver of the host operating system 101.
  • the second state collection module 350 may collect memory available state information of the second OS 101 when a change in activity of the second OS 101 occurs.
  • the change in activity of the second OS 101 may occur when, for example, applications running on the second OS 101 are running or when the first OS 102 is selected and executed by a user. 2 may be a memory state change of the OS 101.
  • the second state collection module 350 requests the first state collection module 310 for the memory state of the second OS 101. Can convey information When the memory of the second OS 101 is insufficient, the second state collection module 350 transmits a memory shortage event to the first state collection module 310 to determine the memory state of the second OS 101. can do.
  • the memory allocation module 370 may be executed in a user level application of the host operating system 101. Also, the memory allocation module 370 transfers the first OS 102 memory to the second OS 101 or transfers the transferred memory to the first OS 102 according to a request of the first memory management module 330. Recovery can be performed again.
  • the memory allocation module 370 may remove the memory of the first OS 102 by distributed computing by the first memory management module 330 installed in each of the first OSs 102. 2 may be transferred to the OS 101 or the memory of the first OS 102 may be transferred to another first OS 102-n (not shown).
  • the electronic device 100 is a smartphone
  • the first OS 102 is a first OS
  • the other first OS 102-1 (not shown) is for an enterprise. It is a second OS
  • the second OS 101 may be a personal second OS.
  • the first OS 102 may use 200 MB of the 1 GB of designated memory to execute the first application 103-1.
  • the first OS 102 requests the memory allocation module 370 to transfer the remaining memory of the remaining 800 MB except the minimum available memory 64 MB for the memory reclaim request to the second enterprise OS 102-1 (not shown). Can be.
  • the second memory management module 390 may be executed in a kernel (not shown) of the host operating system 101 according to an embodiment of the present disclosure. However, this is only one embodiment for the present disclosure. When the electronic device 100 is a desktop computer, the second memory management module 390 may be executed by a driver of the host operating system 101.
  • the second memory management module 390 may receive the memory from the first OS 102 based on the information received from the memory allocation module 370, and transfer the memory back to the first OS 102. Can be. That is, when the first OS 102 makes a memory recovery request to the second OS 101 through the memory allocation module 370, the second memory management module 390 receives the memory received from the first OS 102. May be re-delivered through the first memory management module 330. When the memory of the second OS 101 is insufficient, the second memory management module 390 directly removes the first OS 102 memory from the first memory management module 330 without passing through the memory allocation module 370. Can be delivered.
  • FIG. 4 is a diagram illustrating dynamic memory management when the first operating system 102 is running main, in accordance with an embodiment of the present disclosure.
  • the first memory management module 450 in the first OS 102 is in a memory state of the second OS 101.
  • the memory allocation module 370 may request the memory allocation module 370 to retrieve the memory transferred from the first OS 102 to the second OS 101 (S470).
  • the first memory management module 450 may be configured to include the first memory management module 450. 2 can be implemented to adjust the amount of memory to be recalled so that key services running within OS 101 are not killed. That is, the first OS 102 may be implemented to receive the memory from the second OS 101 in consideration of the designated minimum available memory and the designated threshold memory of the first OS 102.
  • the memory allocation module 410 transmits a memory recovery request received from the first memory management module 450 to the second memory management module 450 (s470) (s480), and the second OS 101 that is a host OS.
  • the memory received from the first OS 102 may be returned to the first OS 102, which is a guest OS, to recover the memory requested by the first OS 102.
  • the electronic device 100 when the electronic device 100 is a smartphone, when the user selects the first OS 102 on the smartphone screen, the first OS 102 interacts with the current user.
  • the smartphone 100 having an interaction may be executed as a main screen in front of the screen.
  • the second OS 101 may be at the back of the screen which does not have interaction with the current user.
  • the first OS 102 may request a recovery to return the memory of the first OS 102 that has been transmitted to the second OS 101.
  • the first memory management module 450 of the first OS 102 may perform main services (eg, running in the second OS 101). For example, the call function and alarm functions) may be implemented to control the amount of memory to be recovered from the second OS 101 so as not to be killed.
  • FIG. 5 is a diagram illustrating dynamic memory management when the first operating system 102 is running as a sub, according to one embodiment of the present disclosure.
  • the first memory management module 550 in the first OS 102 may operate as the second OS 101.
  • the memory state information may be determined (S560), and the memory allocation module 510 may request that the first OS 102 deliver the memory to the second OS 101 (S570).
  • the memory allocation module 510 transfers the memory transfer request received from the first memory management module 550 to the second memory management module 530 (s580), and the second memory management module 530 stores the first memory.
  • the available memory of the first OS 102 may be allocated from the management module 550 (S580).
  • the first OS 102 which is a guest OS, may execute applications in the second OS, which is the host OS 101, without being killed. Therefore, in the memory transfer of the guest OS 102 due to the memory shortage of the host OS 101, unexpected abnormal termination of applications 103-n running in the guest OS 102 can be prevented.
  • an application eg, camera, schedule management
  • the second OS 101 which is the host OS
  • the second OS 101 may be executed as the main in front of the screen of the smartphone 100 having interaction with the current user.
  • the first OS 102 may be at the back of the screen that does not have interaction with the current user. In this case, the first OS 102 may request the second OS 101 to deliver the available memory of the first OS 102. However, the first OS 102 may have a minimum amount of available memory that is running on the back of the screen but that the first OS applications 103-n are not killed. That is, the first memory management module 550 may implement the memory to be transferred to the second OS 101 while leaving the minimum available memory necessary for the first OS 102 to execute.
  • the first OS 102 of the electronic device 100 is in an available memory state of the first OS 102 and the second OS 101.
  • Information may be determined (S610).
  • the first OS 102 and the second OS 101 may collect information according to an application execution state activity and an amount of memory variation of the OS, respectively.
  • the first OS 102 may request memory state information of the second OS 101 from the second OS 101 to collect memory state information of the second OS 101.
  • the first OS 102 of the electronic device 100 may determine whether the first OS 102 is running main or sub. Further, according to an embodiment of the present disclosure, in step s650, the memory availability status information and the first OS 102 of the first OS 102 and the second OS 101 collected by the first OS 102 are stored. Based on the information on whether the electronic device 100 is running in the main, the first OS 102 transfers the memory of the first OS 102 to the second OS 101, or the second OS 101. It may be determined whether to recover the memory delivered to the first OS 102 to be returned.
  • the first OS 102 may request a memory transfer and retrieval from the second OS 101.
  • the second OS 101 receives the memory delivered by the first OS 102 to the second OS 101 and uses it to execute the second OS 101.
  • the memory requested by the first OS 102 may be re-delivered to the first OS 102.
  • FIG. 7A and 7B illustrate a prior art and a memory according to a minimum memory unit for requesting a transfer and retrieval of memory from a first OS 102 to a second OS 101 according to an embodiment of the present disclosure.
  • a graph showing the frequency of delivery and retrieval requests.
  • a memory for transferring and transferring a memory from a first OS 102 to a second OS 101 may be retrieved back to the first OS 102.
  • the minimum available memory amount is not set, it is a graph showing how often the first OS 102 makes a memory recovery request to the second OS 101.
  • the first OS 102 is allocated 1 GB of designated memory, and 650 MB, which is 65% of the 1 GB of memory designated for the first OS 102, is the first OS 102.
  • 650 MB which is 65% of the 1 GB of memory designated for the first OS 102
  • the first OS 102 uses 650 MB, which is a threshold value of the memory of the first OS 102 used by the second OS 101.
  • Each of the excess points may be detected as a lack of memory, and the second OS 101 may frequently request memory recovery requests 1, 2, 3, 4, and 5.
  • the frequent memory reclamation request of the first OS 102 may require the operation of the processor, thus wasting power consumption.
  • the second OS 101 may frequently return memory to the first OS 102. Accordingly, the operation of the second OS 101 may not be stable.
  • the minimum available memory of the first OS 102 is 64 MB, for requesting to recover the memory delivered by the first OS 102 to the second OS 101. Can be set.
  • the first OS 102 may not request a recovery of the memory transferred to the second OS 101 until 64 MB of the designated 1 GB memory remains.
  • the second OS 101 may reduce the frequency of the retrieval requests 1 and 2 from the first OS 102, thereby reducing the power usage.
  • the second OS 101 may execute an application in a stable memory state.
  • the above-described embodiments are merely one embodiment for explaining the minimum available memory setting of the present disclosure, and the minimum available memory of the first OS 102 may vary depending on the average usage of the application memory of the guest OS 102. Can be implemented.
  • the processor 710 may control the host operating system 101, the guest operating system 102, and the memory 720 of the electronic device 100.
  • the memory 720 may store programs and data in which various functions for controlling the host operating system 101 and the guest operating system 102 are implemented.
  • the memory 720 may store information on the minimum available memory usage of the designated first OS in order to request a recovery of the memory delivered by the guest operating system 102 to the host operating system 101.
  • the memory 720 may store a designated period for collecting the memory state information of the second OS 102 from the first OS 102.
  • the memory 720 may store various programs and data necessary for the operation of the electronic device 100.
  • the memory may be implemented as a nonvolatile memory, a volatile memory, a flash memory, a hard disk drive (HDD), or a solid state drive (SSD).
  • the memory is accessed by the processor, and the read / write / modify / delete / update of data by the processor may be performed.
  • the memory 720 may include a memory, a ROM, a RAM, or a memory card (not shown) mounted on an electronic device (eg, a micro SD card or a memory stick).
  • the memory 720 may store software including an OS, a kernel, middleware, an application, and the like.
  • An apparatus or method may include, for example, at least one of executing instructions included in at least one of programs maintained in a computer readable storage medium.
  • a computer eg, a processor
  • the at least one computer may perform a function corresponding to the command.
  • the computer-readable storage medium may be, for example, the memory.
  • Programs include, for example, hard disks, floppy disks, magnetic media (such as magnetic tape), optical media (such as compact disc read only memory) and digital versatile disc (DVD). ), Magneto-optical media (e.g. floptical disks), hardware devices (e.g. read only memory (ROM), random access memory (RAM), or flash memory, etc.)
  • the storage medium is generally included as part of the configuration of the electronic device 100, but may be mounted through a port of the electronic device 100, or electronically. It may be included in an external device (eg, a cloud, a server, or another electronic device) located outside the device 100.
  • the program may be divided and stored in a plurality of storage media, and at least some of the plurality of storage media may be located in an external device of the electronic device.
  • Instructions can include high-level language code that can be executed by a computer using an interpreter, as well as machine code such as produced by a compiler.
  • the aforementioned hardware device may be configured to operate as one or more software modules to perform the operations of the various embodiments, and vice versa.

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Computing Systems (AREA)
  • Quality & Reliability (AREA)
  • Mathematical Physics (AREA)
  • Stored Programmes (AREA)
  • Computer Security & Cryptography (AREA)

Abstract

본 개시는 다중 운영체제(OS)가 실행되는 전자장치에서 호스트 운영시스템 및 게스트 운영시스템 간 동적 메모리 관리 방법을 제공한다. 동적 메모리 관리 방법은, 호스트 운영시스템과 게스트 운영시스템의 가용 메모리 상황에 따라, 게스트 운영시스템이 게스트 운영시스템의 메모리를 호스트 운영시스템으로 전달 및 전달한 메모리를 게스트 운영시스템으로 회수하는 것을 직접 판단하여 호스트 운영시스템에 실행을 요청할 수 있다. 또한, 게스트 운영시스템의 메모리 가용 상태 정보에 따라, 호스트 운영시스템에 요청하여 호스트 운영시스템의 메모리 정보를 지정된 수집 주기에 수집할 수 있다. 또한, 호스트 운영시스템이 게스트 운영시스템의 요청에 따라 게스트 운영시스템의 동적 메모리를 할당할 수 있다.

Description

멀티 운영시스템을 지닌 전자장치 및 이의 동적 메모리 관리 방법
본 개시는 멀티 운영체제를 지닌 전자장치에 관한 것으로서, 더욱 상세하게는, 호스트 운영시스템(host operating system) 및 복수의 게스트 운영시스템(guest operating system)을 지닌 가상화 컴퓨팅 시스템에서, 각각의 운영시스템의 성능을 향상시키도록 호스트 운영시스템과 게스트 운영시스템 사이의 동적 메모리를 관리하는 방법에 관한 것이다.
최근 하나의 디바이스에 복수의 운영시스템을 구동시키는 가상화 기술이 태블릿 PC, 스마트폰, 및 스마트카 등과 같은 모바일 기기로 확장되고 있다. 종래에는 가상화 기술이 데스크탑 컴퓨터나 특정 산업분야에서 국한되어 응용 개발되었다. 그러나 최근에는, 모바일 플랫폼들이 데스크탑 수준의 확장성을 지원하는 범용 운영시스템(OS, Operating System)로 기술이 진보함으로써, 가상화를 모바일 영역까지 확장하는 시도가 활발이 이루어지고 있다.
가상화(Virtualization) 기술은 물리적 장치를 추상화하여 독립된 실행 환경을 제공한다. 가상화를 이용하여 하나의 전자장치에 두 개 이상의 운영시스템이 구동하는 컴퓨팅 시스템에서는, 호스트 운영 시스템(Host Operating System)과 호스트 운영 시스템 환경 내의 가상 머신(Virtual Machine)에서 작동하는 게스트 운영 시스템(Guest Operating System)이 마치 별개의 운영시스템처럼 실행될 수 있다. 이때, 가상 머신에서 동작하는 게스트 OS는 호스트 OS와 전자장치의 CPU, 메모리, 저장공간 등을 서로 공유하고 분배한다.
종래에는, 예를 들어, 복수의 운영 시스템을 사용하는 태블릿 PC 또는 스마트폰의 경우, 어플리케이션의 기능 및 최근 실행 순으로 어플리케이션의 중요도를 부여하였다. 이때, 호스트 OS의 가용 메모리가 부족할 경우, 메모리 사용량이 많고 우선 순위가 낮은 어플리케이션은 실행 중지(kill)된다. 따라서, 호스트 OS의 어플리케이션 형태로 실행되는 가상머신의 게스트 OS는 메모리 사용량이 많기 때문에, 호스트 OS의 메모리가 부족할 경우 종료(kill)되는 가능성이 높은 문제점이 있다. 즉, 게스트 OS는 예상치 않은 비정상 종료를 하게 되는 경우가 발생하게 된다.
이에 따라, 복수의 OS를 사용하는 전자 장치에서, 호스트 운영시스템 및 게스트 운영시스템은 한정된 리소스 및 메모리를 관리하여 각각의 운영시스템의 성능을 향상시킬 수 있도록 하는 기술이 필요하게 된다.
본 개시는 호스트 운영시스템(host operating system) 및 복수의 게스트 운영시스템(guest operating system)을 지닌 가상화 컴퓨팅 시스템을 가진 전자장치에서 각각의 운영시스템의 성능을 향상시키도록 호스트 운영시스템과 게스트 운영시스템 사이의 동적 메모리를 관리하는 방법 및 이러한 방법을 지닌 전자장치를 제공하는 데 목적이 있다.
상기와 같은 목적을 달성하기 위한 본 개시의 일 실시 예에 따른, 다중 운영시스템(OS, Operating System)이 실행되는 전자 장치는, 제1 OS와 제2 OS의 가용 메모리 상황에 따라 상기 제1 OS의 메모리를 상기 제2 OS로 전달 및 상기 전달한 메모리를 회수하는 것을 직접 판단하여 상기 제2 OS에 상기 전달 및 회수의 실행을 요청하는 제1 메모리 관리 모듈; 상기 제1 OS의 메모리 가용 상태 정보를 수집하고, 상기 제2 OS에 요청하여 상기 제2 OS의 메모리 정보를 지정된 수집 주기(interval)에 수집하는 상기 제1 상태 수집 모듈; 상기 제2 OS가 상기 제1 OS의 요청에 따라 상기 제1 OS의 동적 메모리를 할당하는 메모리 할당 모듈; 상기 제2 OS의 메모리 가용 상태 정보를 수집하는 제2 상태 수집 모듈; 및 상기 동적 메모리 할당 정보를 바탕으로, 상기 제1 OS의 메모리를 전달받거나 상기 전달받은 메모리를 상기 제1 메모리로 돌려주어 상기 제2 OS의 메모리를 관리하는 제2 메모리 관리 모듈을 포함한다.
상기 제1 OS 메모리 관리 모듈은, 상기 제1 OS와 상기 제2 OS의 가용 메모리 상태 정보를 판단하고, 상기 제2 OS가 메인으로 실행되고, 상기 제1 OS가 서브로 실행될 때, 상기 제1 OS의 가용 메모리를 상기 제2 OS가 사용하도록 상기 메모리 할당 모듈에 전달을 요청하고, 상기 제1 OS가 메인으로 실행될 때, 상기 제1 OS는 상기 메모리 할당 모듈에 상기 전달한 메모리를 회수 요청할 수 있다.
상기 제1 메모리 관리 모듈은, 상기 판단된 가용 메모리 상황에 따라, 상기 제1 OS에서 상기 제2 OS로 메모리를 전달 및 최소 가용 메모리양을 결정하고, 상기 판단된 가용 메모리 상황 및 상기 최소 가용 메모리 양을 바탕으로, 상기 제1 OS의 메모리를 상기 제2 OS로 전달 및 회수 요청 중 하나를 결정할 수 있다.
상기 최소 가용 메모리양은 상기 제1 OS의 어플리케이션 실행을 위한 최소 단위의 가용 메모리양으로 상기 제1 OS에 의해 지정될 수 있고, 상기 지정된 가용 메모리양에 따라, 상기 제1 OS는 상기 제2 OS에 메모리 회수 요청을 할 수 있으며, 상기 지정된 가용 메모리양은, 상기 어플리케이션의 평균 사용량에 따라 결정될 수 있다.
상기 전달 또는 회수 결정은, 상기 제1 OS가 상기 제2 OS로 메모리 전달 또는 회수 여부를 판단하고, 판단 결과에 따라 상기 제2 OS의 상기 메모리 할당 모듈에 요청할 수 있다.
상기 제1 OS는 복수 개의 제1 OS일 수 있고, 상기 복수개의 제1 OS는, 각 제1 OS에 설치된 제1 메모리 관리모듈이 분산 컴퓨팅으로 상기 제1 OS의 메모리를 상기 제2 OS로 전달 또는 상기 제1 OS로 회수 여부를 결정할 수 있다.
상기 수집 주기는, 상기 제1 OS 및 상기 제2 OS의 메모리 부족 상태근접 여부 및 메모리 사용량 변동 여부에 따라 결정될 수 있고, 상기 제1 OS는, 상기 제1 OS 및 상기 제2 OS의 메모리 부족 이벤트가 발생 시, 상기 지정된 수집 주기를 기다리지 않고 상기 제1 메모리 관리 모듈을 실행할 수 있다.
상기 메모리 할당 모듈은, 상기 제1 OS의 요청에 따라, 상기 제1 OS의 메모리를 상기 제2 OS로 할당하거나, 상기 제1 OS로 상기 할당된 메모리의 회수를 실행하고, 상기 제1 OS가 복수 개일 때, 상기 제1 OS의 메모리를 다른 제1 OS로 할당할 수 있다.
상기 제2 메모리 상태 수집 모듈은, 상기 제2 OS의 상태 변화가 발생할 때, 상기 제2 OS의 메모리 가용 상태 정보를 수집하고, 상기 제1 OS의 상기 정보 요청 시, 상기 제1 OS에 상기 정보를 전달하거나, 또는 상기 제2 OS 메모리 부족 시, 상기 제1 OS에 상기 제2 OS의 메모리 부족 상태를 전달할 수 있다.
상기 제1 OS는 게스트 운영시스템이고, 상기 제1 메모리 관리 모듈 및 제1 상태 수집 모듈은, 가상 머신의 상기 게스트 운영시스템 내에서 실행되고, 상기 제2 OS는 호스트 운영시스템이고, 상기 제2 메모리 관리 모듈, 상기 메모리 할당 모듈, 및 상기 제2 상태 수집 모듈은, 상기 호스트 운영시스템 내에서 실행될 수 있다.
한편, 본 개시의 다른 실시예에 의하면,다중 운영 시스템(OS, Operating System)이 실행되는 전자장치에서 제1 OS 및 제2 OS간 동적 메모리 관리 방법은, 상기 제1 OS와 상기 제2 OS의 가용 메모리 상황에 따라 상기 제1 OS의 메모리를 상기 제2 OS로 전달 및 상기 전달한 메모리를 회수하는 것을 직접 판단하여 상기 제2 OS에 상기 전달 및 회수의 실행을 요청하는 제1 메모리 관리 단계; 상기 제1 OS의 메모리 가용 상태 정보를 수집하고, 상기 제2 OS에 요청하여 상기 제2 OS의 메모리 정보를 지정된 수집 주기에 수집하는 제1 상태 수집 단계; 상기 제2 OS가 상기 제1 OS의 요청에 따라 상기 제1 OS의 동적 메모리를 할당하는 메모리 할당 단계; 상기 제2 OS의 메모리 가용 상태 정보를 수집하는 제2 상태 수집 단계; 및 상기 동적 메모리 할당 정보를 바탕으로, 상기 제1 OS의 메모리를 전달받거나 상기 전달받은 메모리를 상기 제1 메모리로 돌려주어 상기 제2 OS의 메모리를 관리하는 제2 메모리 관리 단계;를 포함한다.
상기 제1 메모리 관리 단계는, 상기 제1 OS와 상기 제2 OS의 가용 메모리 상태 정보를 판단하고, 상기 제2 OS가 메인으로 실행되고, 상기 제1 OS가 서브로 실행될 때, 상기 제1 OS의 가용 메모리를 상기 제2 OS가 사용하도록 상기 메모리 할당 모듈에 전달을 요청하고, 상기 제1 OS가 메인으로 실행될 때, 상기 제1 OS는 상기 메모리 할당 모듈에 상기 전달한 메모리를 회수 요청할 수 있다.
상기 제1 메모리 관리 단계는, 상기 판단된 가용 메모리 상황에 따라, 상기 제1 OS에서 상기 제2 OS로 메모리를 전달 및 최소 가용 메모리양을 결정하고, 상기 판단된 가용 메모리 상황 및 상기 최소 메모리 단위를 바탕으로, 상기 제1 OS의 메모리를 상기 제2 OS로 전달 및 회수 요청 중 하나를 결정할 수 있다.
상기 최소 가용 메모리양은, 상기 제1 OS의 어플리케이션 실행을 위한 최소 단위의 가용 메모리양으로 상기 제1 OS에 의해 지정될 수 있고, 상기 지정된 가용 메모리양에 따라, 상기 제1 OS는 상기 제2 OS에 메모리 회수 요청을 할 수 있으며, 상기 지정된 가용 메모리양은, 상기 어플리케이션의 평균 사용량에 따라 결정될 수 있다.
상기 전달 또는 회수 결정은, 상기 제1 OS가 상기 제2 OS로 메모리 전달 또는 회수 여부를 판단하고, 판단 결과에 따라 상기 제2 OS의 상기 메모리 할당 모듈에 요청할 수 있다.
상기 제1 OS는 복수개의 제1 OS일 수 있고, 상기 복수개의 제1 OS는, 각 제1 OS에 설치된 제1 메모리 관리 모듈이 분산 컴퓨팅으로 제1 OS의 메모리를 제2 OS로 전달 또는 회수 여부를 결정할 수 있다.
상기 수집 주기는, 상기 제1 OS 및 상기 제2 OS의 메모리 부족 상태 근접 여부 및 메모리 사용량 변동 여부에 따라 결정될 수 있고, 상기 제1 OS는, 상기 제1 OS 및 상기 제2 OS의 메모리 부족 이벤트가 발생 시, 상기 설정된 수집 주기를 기다리지 않고 상기 메모리 관리 모듈을 실행할 수 있다.
상기 메모리 할당 모듈은, 상기 제1 OS의 요청에 따라, 상기 제1 OS의 메모리를 상기 제2 OS로 할당하거나, 상기 제1 OS로 회수를 실행하도록 메모리를 할당하고, 상기 제1 OS가 복수 개일 때, 상기 제1 OS의 메모리를 다른 제1 OS로 할당할 수 있다.
상기 제2 메모리 상태 수집 모듈은, 상기 제2 OS의 상태 변화가 발생할 때, 상기 제2 OS의 메모리 가용 상태 정보를 수집하고, 상기 제1 OS의 상기 정보 요청 시, 상기 제1 OS에 상기 정보를 전달하거나, 또는 상기 제2 OS 메모리 부족 시, 상기 제1 OS에 상기 제2 OS의 메모리 부족 상태를 전달할 수 있다.
상기 제1 OS는 게스트 운영시스템이고, 상기 제1 메모리 관리 모듈 및 상기 제1 상태 수집 모듈은, 가상 머신의 게스트 운영시스템 내에서 실행되고, 상기 제2 OS는 호스트 운영시스템이고, 상기 제2 메모리 관리 모듈, 상기 메모리 할당 모듈, 및 상기 제2 상태 수집 모듈은, 호스트 운영시스템 내에서 실행될 수 있다.
이상과 같은 본 개시의 실시예에 따른 복수의 운영 시스템을 가진 전자장치 및 이의 동적 메모리 관리 방법은, 게스트 OS가 게스트 OS 및 호스트 OS의 가용 메모리 상태 정보를 수집하여, 게스트 OS가 사용하지 않는 메모리를 호스트 OS에 전달하고, 게스트 OS의 메모리 부족 시 호스트 OS에 전달한 메모리를 회수하여, 호스트 OS 및 게스트 OS의 메모리 부족으로 인한 성능 저하를 방지할 수 있다.
도 1은 본 개시의 일 실시예에 따른, 게스트 운영시스템(제1 OS) 및 호스트 운영시스템(제2 OS)을 가진 전자장치의 예시도,
도 2는 본 개시의 일 실시예에 따른, 가상화 컴퓨팅 시스템의 일반적인 블록도,
도 3은 본 개시의 일 실시예에 따른, 제1 운영 시스템 및 제2 운영 시스템의 블록도,
도 4는 본 개시의 일 실시예에 따른, 제1 운영 시스템이 메인으로 실행 중일 때 동적 메모리 관리를 나타내는 도면,
도 5는 본 개시의 일 실시예에 따른, 제1 운영 시스템이 서브로 실행 중일 때 동적 메모리 관리를 나타내는 도면,
도 6은 본 개시의 일 실시예에 따른, 동적메모리 관리를 나타내는 순서도,
도 7a 및 도 7b는 본 개시의 일 실시예에 따른, 종래 기술 및 본 개시에서 제1 OS에서 제2 OS로 메모리를 전달 및 회수 요청하기 위한 최소의 메모리 단위에 따른 메모리 전달 및 회수 요청 빈도를 나타내는 그래프, 그리고
도 8은 본 개시의 일 실시예에 따른, 전자장치의 간단한 블록도이다.
본 명세서에서 사용되는 기술적 용어는 단지 특정한 실시 예를 설명하기 위해 사용된 것으로, 본 개시를 한정하려는 의도가 아님을 유의해야 한다. 또한, 본 명세서에서 사용되는 기술적 용어는 본 명세서에서 특별히 다른 의미로 정의되지 않는 한, 본 개시가 속하는 기술 분야에서 통상의 지식을 가진 자에 의해 일반적으로 이해되는 의미로 해석되어야 하며, 과도하게 포괄적인 의미로 해석되거나, 과도하게 축소된 의미로 해석되지 않아야 한다. 또한, 본 명세서에서 사용되는 기술적인 용어가 본 개시의 사상을 정확하게 표현하지 못하는 잘못된 기술적 용어일 때에는, 당업자가 올바르게 이해할 수 있는 기술적 용어로 대체되어 이해되어야 할 것이다. 또한, 본 개시에서 사용되는 일반적인 용어는 사전에 정의되어 있는 바에 따라, 또는 전후 문맥상에 따라 해석되어야 하며, 과도하게 축소된 의미로 해석되지 않아야 한다.
또한, 본 명세서에서 사용되는 단수의 표현은 문맥상 명백하게 다르게 뜻하지 않는 한, 복수의 표현을 포함한다. 본 출원에서, "구성된다" 또는 "포함한다" 등의 용어는 명세서 상에 기재된 여러 구성 요소들, 또는 여러 단계들을 반드시 모두 포함하는 것으로 해석되지 않아야 하며, 그 중 일부 구성 요소들 또는 일부 단계들은 포함되지 않을 수도 있고, 또는 추가적인 구성 요소 또는 단계들을 더 포함할 수 있는 것으로 해석되어야 한다.
또한, 본 명세서에서 사용되는 구성요소에 대한 접미사 "부"는 명세서 작성의 용이함만이 고려되어 부여되거나 혼용되는 것으로서, 그 자체로 서로 구별되는 의미 또는 역할을 갖는 것은 아니다.
또한, 본 명세서에서 사용되는 제1, 제2 등과 같이 서수를 포함하는 용어는 다양한 구성 요소들을 설명하는데 사용될 수 있지만, 상기 구성 요소들은 상기 용어들에 의해 한정되어서는 안 된다. 상기 용어들은 하나의 구성요소를 다른 구성요소로부터 구별하는 목적으로만 사용된다. 예를 들어, 본 개시의 권리 범위를 벗어나지 않으면서 제1 구성요소는 제2 구성 요소로 명명될 수 있고, 유사하게 제2 구성 요소도 제1 구성 요소로 명명될 수 있다.
이하에서는, 첨부된 도면을 참조하여 본 개시에 따른 바람직한 실시예를 상세히 설명하되, 도면 부호에 관계없이 동일하거나 유사한 구성 요소는 동일한 참조 번호를 부여하고 이에 대한 중복되는 설명은 생략하기로 한다.
또한, 본 개시를 설명함에 있어서 관련된 공지 기술에 대한 구체적인 설명이 본 개시의 요지를 흐릴 수 있다고 판단되는 경우 그 상세한 설명을 생략한다. 또한, 첨부된 도면은 본 개시의 사상을 쉽게 이해할 수 있도록 하기 위한 것일 뿐, 첨부된 도면에 의해 본 개시의 사상이 제한되는 것으로 해석되어서는 아니 됨을 유의해야 한다.
이하에서는, 본 개시의 실시예를 첨부도면을 참조하여 상세히 설명하기로 한다. 도 1은 본 개시의 일 실시예에 따른, 호스트 운영시스템(101) 및 복수의 어플리케이션(103-n)을 가진 게스트 운영시스템(102)을 가진 전자장치(100)의 예시도이다. 본 개시의 일 실시예에 따라, 호스트 운영시스템(101)은 제2 운영시스템(제2 OS)일 수 있고, 게스트 운영시스템(102)은 제1 운영시스템(제1 OS)일 수 있다.
또한, 호스트 운영시스템(101) 및 게스트 운영시스템(102)은 각각의 운영시스템 내에서 다양한 데이터와 어플리케이션을 실행할 수 있다. 게스트 운영시스템(102)은 가상 머신(Virtual Machine) 내에서 동작하는 운영시스템일 수 있다. 이때, 호스트 운영시스템(101) 및 게스트 운영시스템(102)은 전자장치(100)의 CPU(미도시), 메모리(미도시), 및 저장공간(미도시)을 공유할 수 있다.
본 개시의 일 실시예에 따라, 게스트 운영시스템(102)은 게스트 운영시스템(102)에서 사용 중이지 않는 메모리를 호스트 운영시스템(101)에 전달할 수 있다. 또한, 게스트 운영시스템(102)이 어플리케이션을 실행하기 위하여 메모리가 필요할 경우, 게스트 운영시스템(102)은 호스트 운영시스템(101)에 전달한 메모리를 회수 요청하여 돌려받을 수 있다.
도 1을 참조하면, 본 개시의 일 실시예에 따라, 전자장치(100)는 호스트 운영시스템(101) 및 게스트 운영시스템(102)을 동시에 가질 수 있다. 또한, 전자장치(100)는 하나의 호스트 운영시스템(101)과 복수의 게스트 운영시스템(102-n)(미도시)을 가질 수 있다.
본 개시의 일 실시예로, 사용자에 의하여 게스트 운영시스템(102)에 의해 실행되는 어플리케이션이 선택되면, 게스트 운영시스템(102) 내에서 동작하는 어플리케이션들이 전자장치(100)의 메인 디스플레이에서 실행되고, 호스트 운영시스템(101)에 의해 실행되는 어플리케이션은 전자장치(100)의 화면의 서브에서 동작하거나 동작을 중지할 수 있다. 즉, 전자장치(100)는 사용자에 의해 선택된 운영시스템을 통하여 선택된 어플리케이션을 실행할 수 있다.
구체적으로, 본 개시의 일 실시예로, 전자장치(100)는 스마트폰, 태블릿 PC 및 스마트카 등의 모바일 장치일 수 있다. 또한, 본 개시의 일 실시예로, 호스트 운영시스템(101) 및 게스트 운영시스템(102)은 모바일 플랫폼 등 다양한 운영시스템이 될 수 있다. 이때, 복수의 어플리케이션(103-n)은 게스트 운영시스템(102)에서 제공하는 어플리케이션들일 수 있다.
도 2는 본 개시의 일 실시예에 따른, 가상화 컴퓨팅 시스템의 일반적인 블록도이다. 가상화 컴퓨팅 환경은 하이퍼바이저의 위치에 따라 "1 유형(type 1)"과 "2 유형(type 2)"로 구분된다. 본 개시에서는 당업자들에게 잘 알려진 통상의 기술에 대해서는 상세한 설명을 생략하도록 하며, 본 개시의 일 실시예에 따른 기술에 대해서 간략히 기술하도록 한다.
도 2를 참조하면, 본 발명의 일 실시예에 따라, 전자장치(100)는 가상화 기술 중 "2 유형(type 2)"의 가상 컴퓨팅 환경이 적용될 수 있다.
"2 유형(type 2)"의 가상화 기술을 적용한 가상 컴퓨팅 환경은 최하위에 CPU(Central Processing Unit)(미도시), 메모리(미도시), 입출력 장치(미도시) 등을 포함하는 하드웨어(미도시)가 위치한다.
하드웨어(미도시) 위에는 호스트 운영시스템(200)이 위치하며, 호스트 운영시스템(200) 위에 하이퍼바이저(Hypervisor)(230) 또는 가상머신 모니터(미도시)가 위치한다.
하이퍼바이저(230)는 다시 가상 머신(VM, Virtual Machine)(250)를 통하여 새로운 운영시스템인 게스트 운영시스템(270)이 독립적으로 실행될 수 있는 환경을 제공한다.
즉, "2 유형"의 가상 컴퓨팅 환경에서, 호스트 운영체제(210)에서 실행되는 어플리케이션(미도시)과 게스트 운영시스템(270) 상에서 실행되는 어플리케이션(290)은 가상적으로 서로 다른 물리적 공간에서 실행되는 효과를 제공한다.
따라서, 두 개의 서로 다른 운영시스템(호스트 OS 및 게스트 OS)이 실제로는 동일한 하드웨어(미도시)를 공유하면서 가상의 서로 다른 물리적 공간에서 동시에 동작될 수 있다.
본 개시의 일 실시예에서는, 게스트 운영시스템(270)이 하나가 도시되었으나, 게스트 운영시스템(270)은 복수 개로 동작할 수 있다. 즉, N개의 가상 머신(250n) 위에 각 가상머신(250n)에 대응하는 N개의 게스트 운영시스템(270n)이 위치할 수 있다. 또한, N개의 게스트 운영시스템(270n)에서 각 게스트 운영시스템(270n)에 대응하는 M개의 어플리케이션(290m)이 동작할 수 있다.
도 3은 본 개시의 일 실시예에 따른, 제1 운영 시스템 및 제2 운영 시스템의 블록도이다. 도 3을 참조하면, 제1 운영 시스템은 게스트 OS(102)일 수 있고, 제2 운영시스템은 호스트 OS(101)일 수 있다. 게스트 OS(102)는 가상 머신(미도시) 내에서 동작할 수 있다.
도 3에서, 본 발명의 일 실시예에 따라, 제1 상태수집모듈(310) 및 제1 메모리 관리 모듈(330)은 가상 머신(미도시) 내에 로드된(loaded) 사용자 레벨 어플리케이션(user-level application)일 수 있다. 구체적으로, 제1 상태수집모듈(310)은 제1 OS(102)의 메모리 가용 상태 정보를 수집할 수 있다. 이때, 메모리 가용 상태 정보는 제1 OS(102)에 지정된 메모리 크기(total memory)일 수 있다. 또한, 메모리 가용 상태 정보는, 제1 OS(102)가 지정된 메모리 크기(total memory)중 제1 OS(102) 내에서 동작하는 어플리케이션들을 실행하고 남는 메모리 크기(free memory)일 수 있다. 그리고, 메모리 가용 상태 정보는, 제1 OS(102)가 제2 OS(102)에게 전달할 수 있는 사용 가능한 메모리의 크기(available memory)일 수 있다.
또한, 제1 상태수집모듈(310)은 제2 OS(101)의 제2 상태수집모듈(350)에 요청하여 제2 OS(101)의 메모리 정보를 지정된 수집 주기에 수집할 수 있다. 그리고, 제1 상태수집모듈(310)에서 수집된 정보는 제1 메모리 관리모듈(330)에 전달될 수 있다. 이때, 본 개시의 일 실시예에 따라, 제1 상태수집모듈(310)은 제2 OS(101)의 메모리 정보 수집을 실행할 때, 오버헤드를 최소화하기 위하여 가상 메모리 정보 레지스터 액세스를 통해 수행될 수 있다.
그리고, 제1 상태수집모듈(310)은 제1 OS(102) 및 제2 OS(101)의 메모리 부족 상태(memory pressure)의 근접 여부 및 각 OS(102, 101)의 메모리 사용량 변동에 따라서 제1 OS(102) 및 제2 OS(101)의 메모리 상태 정보를 수집하기 위한 주기를 지정할 수 있다. 이때, 제1 OS(102)는 제1 OS(102) 및 제2 OS(101)의 메모리 상태 정보를 바탕으로, 제1 OS(102)가 제2 OS(101)에 메모리를 전달할 수 있고, 제2 OS(101)에 전달한 메모리를 회수 요청할 수 있다.
그러나, 불필요하게 잦은 상태 정보 수집 및 정보 요청은 CPU의 잦은 처리를 발생시켜 전력을 많이 소모시킬 수 있다. 따라서, 제1 OS(102)의 지정된 메모리(total memory)에서 제2 운영시스템(101)에 전달한 메모리의 양이 제1 OS(102)의 지정된 메모리(total memory)의 지정된 임계값(threshold) 이상일 때, 제1 OS(102)의 잔여 메모리의 변동량에 따라 수집 주기가 변동되도록 할 수 있다.
구체적으로, 예를 들어, 본 발명의 일 실시예에서, 제1 OS(102)는 1GB의 지정된 메모리(total memory)가 할당되어 있을 수 있다. 즉, 사용자가 전자장치(100)에서 제1 OS(102)를 실행하기 위해 선택하면, 제1 OS(102)에는 1GB 크기가 할당되어 1GB 메모리 한도 내에서 제1 OS (102)를 실행할 수 있도록 메모리가 지정될 수 있다.
이때, 예를 들어, 전자 장치(100)가 스마트폰일 때, 사용자가 전자장치(100)에서 제1 OS (102)의 제1 어플리케이션(103-1)를 선택하면, 제1 OS(102)는 지정된 1GB에서 200MB를 제1 어플리케이션(103-1)을 실행하는 데 할당할 수 있다. 또한, 사용자가 제4 어플리케이션(103-4)을 선택하면, 제1 OS(102)는 200MB를 제4 어플리케이션(103-4)을 실행하는 데 할당할 수 있다. 이때, 제1 OS (102)는 1GB 중 400MB의 메모리를 사용하고, 나머지 600MB 중 제2 OS(101)의 메모리 부족 상태에 따라 제2 OS (101)에 전달할 수 있다.
이때, 제1 OS(102)가 제n 어플리케이션(103-n)을 실행하기 위해 사용 중인 메모리 및 제1 OS(102)가 제2 OS (101)에 전달한 메모리의 양이, 제1 OS (102)의 지정된 메모리(total memory)인 1GB 중 지정된 임계값(threshold)인 650MB(총 메모리의 65%)를 초과하면, 제1 상태수집모듈(310)은 제2 상태수집모듈(350)에 제2 OS (101)의 메모리 상태 정보를 요청할 수 있다.
예를 들어, 제1 OS (102)가 지정된 메모리(total memory)의 지정된 임계값(65%)의 95%를 초과하는 메모리가 사용 중이라면, 제1 상태수집모듈(310)은 2초 주기로 제2 OS (101)에 메모리 상태 정보를 요청할 수 있다. 즉, 제1 OS (102)의 지정된 메모리 1GB 중, 제1 OS(102)를 실행하기 위한 메모리 크기로 지정된 임계값인 650MB(65%)의 95%(617MB)이상이 사용 중이면, 제1 OS(102)를 실행하기 위한 메모리 여유분이 부족할 수 있으므로 잦은 주기로 호스트 OS(101)에 상태정보를 요청할 수 있다.
만약, 예를 들어, 제1 OS(102)가 지정된 메모리(total memory)의 지정된 임계값(65%)의 80%를 초과하고 95%이하의 메모리가 사용 중이라면, 제1 상태수집모듈(310)은 4초 주기로 제2 OS(101)에 메모리 상태 정보를 요청할 수 있다. 즉, 제1 OS(102)의 지정된 메모리 1GB 중, 제1 OS(102)를 실행하기 위한 메모리 크기로 지정된 임계값인 650MB(65%)의 80% 내지 95% (520MB 내지 617MB)가 사용 중이면, 제1 OS(102)의 메모리 사용량이 줄어들수록 수집 주기를 4초에 x초씩 더하여(4+x) 수집 주기를 늘려갈 수 있다.
또한, 예를 들어, 제1 OS(102)가 지정된 메모리(total memory)의 지정된 임계값(65%)의 80%이하의 메모리가 사용 중이라면, 제1 상태수집모듈(310)은 10초 주기로 제2 OS(101)에 메모리 상태 정보를 요청할 수 있다. 즉, 제1 OS(102)의 지정된 메모리 1GB 중, 제1 OS(102)를 실행하기 위한 메모리 크기로 지정된 임계값인 650MB(65%)의 80%(520MB) 이하로 사용 중이면, 제1 OS(102)의 메모리에 여유가 많이 있으므로, 수집 주기를 제1 OS(102)의 메모리 사용량이 감소함에 따라 10초에 x초씩 더하여(10+x) 수집 주기를 늘려갈 수 있다.
그러나, 이상에서 예시한 수집 주기는 본 개시를 설명하기 일 실시예일 뿐, 게스트 OS(102)의 지정된 메모리(total memory)는 게스트 OS(102)에 따라 다르게 구현될 수 있다. 또한, 게스트 OS(102)의 지정된 메모리에 대한 임계값(threshold) 및 그에 따른 주기 설정도 게스트 OS(102)의 메모리 사용량과 메모리 변동량에 따라 다양하게 구현될 수 있다.
제1 메모리 관리 모듈(330)은 게스트 운영시스템(102) 내의 커널(미도시)에서 실행될 수 있다. 그러나, 이것은 본 개시를 위한 일 실시예일 뿐, 전자장치(100)가 데스크탑 컴퓨터일 경우, 제1 메모리 관리 모듈(330)은 게스트 운영시스템(102)의 드라이버(미도시)일 수 있다.
그리고, 제1 메모리 관리 모듈(330)은 제1 상태수집모듈에서 수집된 제1 OS(102) 및 제2 OS(101)의 가용 메모리 상황에 따라 제1 OS(102)의 메모리를 제2 OS(101)로 전달하는 것을 판단할 수 있고, 제2 OS(101)에 전달한 메모리를 다시 제1 OS(102)로 회수하도록 판단할 수 있다. 이 때, 제1 메모리 관리 모듈(330)은 판단된 메모리 전달 및 회수 결정을 메모리 할당 모듈(370)에 요청하고, 메모리 할당 모듈(370)은 제2 메모리 관리 모듈(390)에 제1 메모리 관리 모듈(330)로부터 받은 요청을 전달한다. 제1 메모리 관리 모듈(330)은 제2 OS(101)에서 메모리 부족 이벤트가 발생할 시, 메모리 할당 모듈(370)을 거치지 않고 직접 제2 메모리 관리 모듈(390)을 통하여, 제1 OS(102)의 메모리를 제2 OS(101)로 전달할 수 있다. 또한, 제1 메모리 관리 모듈(330)은 제1 OS(102)에서 메모리 부족 이벤트가 발생할 시, 즉시 메모리 할당 모듈(370)에 제1 OS(102)가 제2 OS(101)에 전달한 메모리를 회수하도록 요청할 수 있다.
또한, 제1 메모리 관리 모듈(330)은 제1 OS(102)가 전자장치(100)에서 메인으로 실행되고 있을 때, 메모리 할당 모듈(370)에 요청하여 제1 OS(102)가 제2 OS(101)에 전달한 메모리를 회수할 수 있다. 이때, 제1 메모리 관리 모듈(330)은 제2 OS(101)로부터 전달한 메모리를 돌려받기 위해 회수 요청을 할 때, 제2 OS(101)가 극한의 메모리 부족으로 제2 OS(101) 내에서 실행 중인 주요 서비스들이 중지(kill)되지 않도록 할 수 있다. 즉, 제1 OS(102)의 지정된 최소 가용 메모리와 지정된 임계 메모리를 고려하여 제2 OS(101)로부터 메모리를 돌려받을 수 있도록 구현할 수 있다.
예를 들어, 본 개시의 일 실시예에 따라, 전자장치(100)가 스마트폰일 때, 사용자가 스마트폰(100) 화면에서 제1 OS(102)를 선택할 때, 게스트 OS인 제1 OS(102)는 현재 사용자와 인터렉션(interaction)을 갖는 스마트폰(100) 화면 전면에서 메인으로 실행될 수 있다. 반면, 제2 OS(101)는 현재 사용자와 인터렉션을 갖지 않는 화면 후면에 있을 수 있다. 이때, 제1 OS(102)는 제2 OS(101)에 전달했던 제1 OS(102)의 메모리를 돌려받기 위해 회수 요청을 할 수 있다. 그러나, 제2 OS(101)의 메모리 가용량이 극한의 부족상태일 경우, 제1 OS(102)의 제1 메모리관리모듈은 제2 OS(101) 내에서 실행중인 주요 서비스들(예를 들어, 통화 기능, 알람 기능 들)이 중지(kill)되지 않도록, 제2 OS(101)로부터 회수할 메모리 양을 제어하도록 구현할 수 있다.
반면, 제1 메모리 관리 모듈(330)은 제2 OS(101)가 전자장치(100)에서 메인으로 실행되고 제1 OS(102)는 서브로 실행될 때, 메모리 할당 모듈(370)에 요청하여 제1 OS(102)의 메모리를 제2 OS(101)에 전달할 수 있다.
예를 들어, 본 개시의 일 실시예에 따라, 전자장치(100)가 스마트폰일 때, 사용자가 스마트폰(100) 화면에서 제2 OS(101) 내에서 동작하는 어플리케이션을 선택할 때, 호스트 OS인 제2 OS(101)는 현재 사용자와 인터렉션(interaction)을 갖는 스마트폰(100) 화면 전면에서 메인으로 실행될 수 있다. 반면, 제1 OS(102)는 현재 사용자와 인터렉션을 갖지 않는 화면 후면에 있을 수 있다. 이때, 제1 OS(102)는 제1 OS(102)의 가용 메모리를 최대한 많이 제2 OS(101)에 전달할 수 있다. 그러나, 제1 OS(102)가 실행될 수 있는 최소 가용 메모리양에 도달할 경우, 제1 OS(102)는 제2 OS(101)에 전달했던 메모리를 돌려달라고 회수 요청할 수 있다.
그리고, 제1 메모리 관리 모듈(330)은 제1 상태수집모듈(310)에서 수집된 제1 OS(102) 및 제2 OS(101)의 가용 메모리 상태 정보에 따라, 제1 OS(102)에서 제2 OS(101)로 메모리를 전달 및 전달한 메모리를 제1 OS(102)로 다시 회수하기 위한 최소 가용 메모리 양을 결정할 수 있다. 최소 가용 메모리양은, 제1 OS(102)의 어플리케이션들이 실행되기 위한 최소 단위의 가용 메모리로써, 어플리케이션의 평균 메모리 사용량에 따라 결정될 수 있다. 이때, 최소 단위의 가용 메모리는 제1 OS(102)에 의해 미리 지정될 수 있다.
본 개시의 일 실시예에 따라, 예를 들어, 제1 OS(102)는 1GB의 지정된 메모리를 할당받을 수 있다. 그리고, 제1 OS(102)에 지정된 메모리 1GB의 65%인 650MB를 임계값으로 지정할 수 있다. 그리고, 제1 OS(102)가 제2 OS(101)에 전달한 메모리를 회수하기 위한 최소 가용 메모리양을 64MB로 지정할 수 있다. 이때, 제1 OS(102)는 1GB 중 64MB가 남아있을 때까지, 제1 OS(102)는 제2 OS(101)에 전달한 메모리의 회수 요청을 하지 않을 수 있다. 따라서, 제2 OS(101)의 메모리할당모듈(370)에 메모리 전달 및 회수 요청하는 빈도수가 줄어들어 전력 사용을 줄일 수 있고, 제2 OS(101)는 안정된 메모리 상태에서 어플리케이션을 실행할 수 있다.
반면, 최소 가용 메모리양을 지정하지 않을 경우, 제1 메모리 관리 모듈(330)은 제1 상태수집모듈(310)에서 지정된 임계값(650MB)을 바탕으로, 제2 OS(101)에 메모리 회수 요청을 할 수 있다. 이때, 호스트 OS인 제2 OS(101)가 어플리케이션을 실행하기 위해 메모리 사용량이 많을 경우, 임계값인 650MB를 자주 초과할 수 있다. 이때, 제1 OS(102)는 제2 OS(101)의 메모리할당모듈(370)에 자주 메모리 회수 요청을 할 수 있다.
그러나, 상술한 예시들은, 제1 메모리관리 모듈(330)의 최소 가용 메모리 설정에 대한 설명을 위한 본 발명의 일 실시예일뿐, 본 개시는 게스트 OS(102)의 어플리케이션(103-n) 메모리 평균 사용량에 따라 다양하게 구현될 수 있다.
따라서, 제1 메모리 관리 모듈(330)는 제1 OS(102)가 제2 OS(101)에 전달한 메모리를 회수 요청하기 위한 최소 가용 메모리를 지정함으로써, 제1 메모리 관리 모듈(330)은 제2 OS(101)의 메모리 부족을 인식하는 빈도수를 줄일 수 있다. 또한, 제1 OS(102)가 제2 OS(101)에 메모리 회수 요청하는 빈도수를 줄일 수 있다. 따라서, 제2 OS(101)는 부족한 메모리를 제1 OS(102)로부터 전달받아 안정적으로 어플리케이션을 실행할 수 있고, 요청 빈도수가 줄어들어 전력소모도 줄일 수 있다.
제2 상태수집모듈(350)은 호스트 운영시스템(101)의 커널(미도시) 메모리 관리 시스템에서 실행될 수 있고, 호스트 운영시스템(101)의 사용자 레벨에서 실행될 수 있다. 그러나, 이것은 본 개시를 위한 일 실시예일 뿐, 전자 장치(100)가 데스크탑 컴퓨터일 경우, 제2 상태수집모듈(350)은 호스트 운영시스템(101)의 드라이버에서 실행될 수 있다.
그리고, 제2 상태수집모듈(350)은 제2 OS(101)의 상태(activity) 변화가 발생할 때, 제2 OS(101)의 메모리 가용 상태 정보를 수집할 수 있다. 제2 OS(101)의 상태(activity) 변화는, 예를 들어, 제2 OS(101) 상에서 동작되는 어플리케이션들이 실행 중이거나, 제1 OS(102)가 사용자에 의해 선택되어 실행될 때 발생하는 제2 OS(101)의 메모리 상태 변화일 수 있다.
또한, 제2 상태수집모듈(350)은 제1 OS(102)가 제2 OS(101)의 메모리 상태정보를 요청할 때, 제1 상태수집모듈(310)에 제2 OS(101)의 메모리 상태정보를 전달할 수 있다. 그리고, 제2 상태수집모듈(350)은, 제2 OS(101)의 메모리 부족 시, 제1 상태수집모듈(310)에 메모리 부족 이벤트를 전달하여 제2 OS(101)의 메모리 상태를 파악하도록 할 수 있다.
메모리 할당 모듈(370)은 호스트 운영시스템(101)의 사용자 레벨 어플리케이션에서 실행될 수 있다. 또한, 메모리 할당 모듈(370)은 제1 메모리 관리 모듈(330)의 요청에 따라, 제1 OS(102) 메모리를 제2 OS(101)로 전달하거나, 전달한 메모리를 제1 OS(102)로 다시 회수하는 것을 실행할 수 있다.
메모리 할당 모듈(370)은, 제1 OS(102)가 복수 개일 때, 각 제1 OS(102)에 설치된 제1 메모리 관리모듈(330)이 분산 컴퓨팅으로 제1 OS(102)의 메모리를 제2 OS(101)로 전달 또는 제1 OS(102)의 메모리를 다른 제1 OS(102-n)(미도시)로 전달할 수 있다.
예를 들어, 본 개시의 일 실시예에 따라, 전자 장치(100)는 스마트 폰이고, 제1 OS(102)는 제1 OS이고, 다른 제1 OS(102-1)(미도시)는 기업용 제2 OS이고, 제2 OS(101)는 개인용 제2 OS일 수 있다. 이때, 제1 OS(102)는 1GB의 지정된 메모리 중, 제1 애플리케이션(103-1)을 실행하기 위해 200 MB 사용할 수 있다. 제1 OS(102)는 나머지 800 MB 중 메모리 회수 요청을 위한 최소 가용 메모리 64 MB를 제외한 나머지 메모리를 기업용 제2 OS(102-1)(미도시)에 전달하도록 메모리할당모듈(370)에 요청할 수 있다.
제2 메모리 관리 모듈(390)은, 본 개시의 일 실시예에 따라, 호스트 운영시스템(101)의 커널(미도시)에서 실행될 수 있다. 그러나, 이는 본 개시를 위한 일 실시예일 뿐, 전자장치(100)가 데스크탑 컴퓨터일 경우, 제2 메모리 관리 모듈(390)은 호스트 운영시스템(101)의 드라이버에서 실행될 수 있다.
또한, 제2 메모리 관리 모듈(390)은 메모리 할당 모듈(370)에서 수신한 정보를 바탕으로, 제1 OS(102)로부터 메모리를 전달받을 수 있고, 제1 OS(102)로 메모리를 다시 전달할 수 있다. 즉, 제1 OS(102)에서 메모리 할당모듈(370)을 통해 제2 OS(101)에 메모리 회수 요청을 할 경우, 제2 메모리 관리 모듈(390)은 제1 OS(102)로부터 전달받은 메모리를 제1 메모리관리모듈(330)을 통해 재전달할 수 있다. 그리고, 제2 OS(101)의 메모리가 부족할 때, 제2 메모리관리모듈(390)은 메모리할당모듈(370)을 통하지 않고 직접 제1 메모리관리모듈(330)로부터 제1 OS(102) 메모리를 전달받을 수 있다.
도 4는 본 개시의 일 실시예에 따른, 제1 운영 시스템(102)이 메인으로 실행 중일 때 동적 메모리 관리를 나타내는 도면이다. 도 4를 참조하면, 전자장치(100)에서 제1 OS(102)가 메인으로 실행 중일 때, 제1 OS(102) 내의 제1 메모리 관리모듈(450)은 제2 OS(101)의 메모리 상태 정보를 파악하고(s460), 메모리 할당 모듈(370)에 제1 OS(102)가 제2 OS(101)에 전달한 메모리를 회수 요청할 수 있다(s470).
이때, 제1 메모리 관리 모듈(450)이 메모리할당모듈(410)로부터 전달받은 제2 OS(101)의 메모리 상태(s460)가 극한의 메모리 부족일 때, 제1 메모리 관리 모듈(450)은 제2 OS(101) 내에서 실행 중인 주요 서비스들이 중지(kill)되지 않도록 회수할 메모리 양을 조절하도록 구현할 수 있다. 즉, 제1 OS(102)가 제1 OS(102)의 지정된 최소 가용 메모리와 지정된 임계 메모리를 고려하여 제2 OS(101)로부터 메모리를 돌려받을 수 있도록 구현할 수 있다.
그리고, 메모리 할당 모듈(410)은 제1 메모리 관리모듈(450)로부터 받은 메모리 회수 요청을(s470) 제2 메모리 관리모듈(450)에 전달하고(s480), 호스트 OS인 제2 OS(101)에서 제1 OS(102)로부터 전달받은 메모리를 게스트 OS인 제1 OS(102)로 돌려주어 제1 OS(102)가 요청한 메모리를 회수할 수 있도록(s490) 구현할 수 있다.
예를 들어, 본 개시의 일 실시예에 따라, 전자장치(100)가 스마트폰일 때, 사용자가 스마트폰 화면에서 제1 OS(102)를 선택하면, 제1 OS(102)는 현재 사용자와 인터렉션(interaction)을 갖는 스마트폰(100) 화면 전면에서 메인으로 실행될 수 있다.
반면, 제2 OS(101)는 현재 사용자와 인터렉션을 갖지 않는 화면 후면에 있을 수 있다. 이때, 제1 OS(102)는 제2 OS(101)에 전달했던 제1 OS(102)의 메모리를 돌려받기 위해 회수 요청을 할 수 있다. 그러나, 제2 OS(101)의 메모리 가용량이 극한의 부족상태일 경우, 제1 OS(102)의 제1 메모리 관리모듈(450)은 제2 OS(101) 내에서 실행중인 주요 서비스들(예를 들어, 통화 기능, 알람 기능 들)이 중지(kill)되지 않도록, 제2 OS(101)로부터 회수할 메모리 양을 제어하도록 구현할 수 있다.
도 5는 본 개시의 일 실시예에 따른, 제1 운영 시스템(102)이 서브로 실행 중일 때 동적 메모리 관리를 나타내는 도면이다. 도 5를 참조하면, 전자장치(100)에서 호스트 OS인 제2 OS(101)가 메인으로 실행 중일 때, 제1 OS(102) 내의 제1 메모리 관리모듈(550)은 제2 OS(101)의 메모리 상태 정보를 파악하고(s560), 메모리 할당 모듈(510)에 제1 OS(102)가 제2 OS(101)에 메모리를 전달하도록 요청할 수 있다(s570).
그리고, 메모리 할당 모듈(510)은 제1 메모리 관리 모듈(550)로부터 받은 메모리 전달 요청을 제2 메모리 관리 모듈(530)에 전달하고(s580), 제2 메모리관리모듈(530)은 제1 메모리 관리 모듈(550)로부터 제1 OS(102)의 가용 메모리를 할당받을 수 있다(s580). 이때, 게스트 OS인 제1 OS(102)는 중지(kill)되지 않은 상태로 호스트 OS(101)인 제2 OS 내의 어플리케이션들이 실행될 수 있다. 따라서, 호스트 OS(101)의 메모리 부족으로 인한 게스트 OS(102)의 메모리 전달에 있어서, 게스트 OS(102) 내에서 실행중인 어플리케이션(103-n)들의 예상치 않은 비정상 종료를 방지할 수 있다.
예를 들어, 본 개시의 일 실시예에 따라, 전자장치(100)가 스마트폰일 때, 사용자가 스마트폰 (100)화면에서 제2 OS(101) 내에서 실행 중인 어플리케이션(예, 카메라, 일정관리, 등)을 선택할 때, 호스트 OS인 제2 OS(101)는 현재 사용자와 인터렉션(interaction)을 갖는 스마트폰(100) 화면 전면에서 메인으로 실행될 수 있다.
반면, 제1 OS(102)는 현재 사용자와 인터렉션을 갖지 않는 화면 후면에 있을 수 있다. 이때, 제1 OS(102)는 제2 OS(101)에 제1 OS(102)의 가용 메모리를 전달하도록 요청을 할 수 있다. 그러나, 제1 OS(102)는 화면 후면에서 실행 중이나 제1 OS 어플리케이션(103-n)들이 중지(kill)되지 않도록 지정된 최소 가용 메모리양을 가질 수 있다. 즉, 제1 메모리관리모듈(550)은 제1 OS(102)가 실행하는데 필요한 최소 가용 메모리를 남겨두고, 제2 OS(101)에 메모리를 전달할 수 있도록 구현할 수 있다.
도 6은 본 개시의 일 실시예에 따른, 동적메모리 관리를 나타내는 순서도이다. 도 6을 참조하면, 본 개시의 일 실시예에 따라, s610 단계에서, 전자장치(100)의 제1 OS(102)는, 제1 OS(102) 및 제2 OS(101)의 가용 메모리 상태 정보를 판단할 수 있다(s610). 이때, 제1 OS(102) 및 제2 OS(101)는 각각 OS의 어플리케이션 실행 상태 변화(activity) 및 메모리 변동량에 따른 정보를 수집할 수 있다. 그리고, 제1 OS(102)는 제2 OS(101)에 제2 OS(101)의 메모리 상태 정보를 요청하여 제2 OS(101)의 메모리 상태 정보를 수집할 수 있다.
그리고, 본 개시의 일 실시예에 따라, s630 단계에서, 전자장치(100)의 제1 OS(102)는 제1 OS(102)가 메인으로 실행 중인지, 서브로 실행 중인지 판단할 수 있다. 또한, 본 개시의 일 실시예에 따라, s650 단계에서, 제1 OS(102)에서 수집된 제1 OS(102) 및 제2 OS(101)의 메모리 가용상태 정보 및 제1 OS(102)가 전자장치(100)의 메인에서 실행되고 있는 지에 대한 정보를 바탕으로, 제1 OS(102)는 제1 OS(102)의 메모리를 제2 OS(101)로 전달할 것인지, 제2 OS(101)에 전달한 메모리를 다시 제1 OS(102)가 돌려받도록 회수할 것인지 판단할 수 있다.
또한, 본 개시의 일 실시예에 따라, s670 단계에서, 판단된 메모리 전달 및 회수에 따라, 제1 OS(102)는 제2 OS(101)에 메모리 전달 및 회수를 요청할 수 있다. 본 개시의 일 실시예에 따라, s690 단계에서, 제2 OS(101)는 제1 OS(102)가 제2 OS(101)에 전달한 메모리를 전달받아 제2 OS(101)를 실행하는 데 사용할 수 있고, 제1 OS(102)가 회수 요청한 메모리를 제1 OS(102)에 재전달할 수 있다.
도 7a 및 도 7b는 본 개시의 일 실시예에 따른, 종래 기술 및 본 개시에서 제1 OS(102)에서 제2 OS(101)로 메모리를 전달 및 회수 요청하기 위한 최소의 메모리 단위에 따른 메모리 전달 및 회수 요청 빈도를 나타내는 그래프이다.
도 7a를 참조하면, 본 개시의 일시예에 따른 종래의 기술로, 제1 OS(102)에서 제2 OS(101)로 메모리를 전달 및 전달한 메모리를 제1 OS(102)로 다시 회수하기 위한 최소 가용 메모리 양을 설정하지 않을 때, 제1 OS(102)가 제2 OS(101)에 메모리 회수 요청을 하는 빈도수를 나타내는 그래프이다.
본 개시의 일 실시예에 따라, 예를 들어, 제1 OS(102)가 1GB의 지정된 메모리를 할당받고, 제1 OS(102)에 지정된 메모리 1GB의 65%인 650MB이 제1 OS(102)를 실행하기 위한 임계값으로 지정된 경우일 수 있다. 이때, 제2 OS(101)에서 어플리케이션을 실행하기 위한 메모리 사용량이 많을 경우, 제1 OS(102)는 제2 OS(101)가 사용하는 제1 OS(102)의 메모리가 임계값인 650MB을 초과하는 지점마다 메모리 부족으로 인지(host pressure detect)하여, 제2 OS(101)에 빈번하게 메모리 회수 요청(①, ②, ③, ④, ⑤)을 할 수 있다.
이때, 제1 OS(102)의 잦은 메모리 회수 요청은 프로세서의 동작을 요구하므로 소모전력을 낭비시킬 수 있다. 또한, 제1 OS(102)의 잦은 메모리 회수 요청에 따라, 제2 OS(101)는 제1 OS(102)로 잦은 메모리 반환이 발생할 수 있다. 이에 따라, 제2 OS(101)의 동작이 안정적이지 않을 수 있다.
도 7b를 참조하면, 본 개시의 일 실시예에 따라, 제1 OS(102)가 제2 OS(101)에 전달한 메모리를 회수 요청하기 위한, 제1 OS(102)의 최소 가용 메모리를 64MB로 설정할 수 있다. 이때, 제1 OS(102)는 지정된 1GB 메모리 중 64MB가 남아있을 때까지, 제2 OS(101)에 전달한 메모리의 회수 요청을 하지 않을 수 있다. 따라서, 제2 OS(101)는 제1 OS(102)로부터의 회수 요청(①, ②) 빈도수가 줄어들어 전력 사용을 줄일 수 있다. 또한, 제2 OS(101)는 안정된 메모리 상태에서 어플리케이션을 실행할 수 있다.
그러나, 상술한 실시 예시들은, 본 개시의 최소 가용 메모리 설정에 대한 설명을 위한 일 실시예일뿐, 제1 OS(102)의 최소 가용 메모리는 게스트 OS(102)의 어플리케이션 메모리 평균 사용량에 따라 다양하게 구현될 수 있다.
도 8은 본 개시의 일 실시예에 따른, 전자장치의 간단한 블록도이다. 도 8을 참조하면, 프로세서(710)는 전자장치(100)의 호스트 운영시스템(101), 게스트 운영시스템(102), 메모리(720)를 제어할 수 있다. 메모리(720)는, 호스트 운영시스템(101) 및 게스트 운영시스템(102)을 제어하는 다양한 기능이 구현된 프로그램 및 데이터를 저장할 수 있다. 또한, 메모리(720)는 게스트 운영시스템(102)이 호스트 운영시스템(101)에 전달한 메모리를 회수 요청하기 위하여 지정된 제1 OS의 최소 가용 메모리 사용량에 대한 정보를 저장할 수 있다. 그리고, 메모리(720)는 제1 OS(102)에서 제2 OS(102)의 메모리 상태 정보를 수집할 수 있는 지정된 주기를 저장할 수 있다.
메모리(720)는 전자장치(100)의 동작에 필요한 각종 프로그램 및 데이터를 저장할 수 있다. 메모리는 비휘발성 메모리, 휘발성 메모리, 플래시메모리(flash-memory), 하드디스크 드라이브(HDD) 또는 솔리드 스테이트 드라이브(SSD) 등으로 구현될 수 있다. 메모리는 프로세서에 의해 액세스되며, 프로세서에 의한 데이터의 독취/기록/수정/삭제/갱신 등이 수행될 수 있다. 본 개시에서 메모리(720)는 메모리, ROM, RAM, 또는 전자장치에 장착되는 메모리 카드(미도시)(예를 들어, micro SD 카드, 메모리 스틱)를 포함할 수 있다. 메모리(720)에는 OS, 커널, 미들웨어, 어플리케이션 등을 포함하는 소프트웨어가 저장될 수 있다.
다양한 실시 예에 따른 장치 또는 방법은, 예컨대, 컴퓨터로 읽을 수 있는 저장매체(computer readable storage medium)에 유지되는(maintain) 프로그램들 중 적어도 하나의 프로그램에 포함된 명령어(instructions)를 실행하는 적어도 하나의 컴퓨터(예: 프로세서)에 의하여 수행될 수 있다.
상기 명령어가 컴퓨터(예: 프로세서)에 의해 실행될 경우, 상기 적어도 하나의 컴퓨터는 상기 명령어에 해당하는 기능을 수행할 수 있다. 이 때, 컴퓨터로 읽을 수 있는 저장매체는, 예를 들면, 상기 메모리가 될 수 있다.
프로그램은, 예로, 하드디스크, 플로피디스크, 마그네틱 매체(magnetic media)(예: 자기테이프), 광기록 매체 (optical media)(예: CD-ROM(compact disc read only memory), DVD (digital versatile disc), 자기-광 매체(magneto-optical media)(예: 플롭티컬 디스크 (floptical disk)), 하드웨어 장치(예: ROM (read only memory), RAM (random access memory), 또는 플래시 메모리 등) 등과 같은 컴퓨터로 읽을 수 저장 매체에 포함될 수 있다. 이 경우, 저장 매체는 일반적으로 전자 장치(100)의 구성의 일부로 포함되나, 전자 장치(100)의 포트(port)를 통하여 장착될 수도 있으며, 또는 전자 장치(100)의 외부에 위치한 외부 기기(예로, 클라우드, 서버 또는 다른 전자 기기)에 포함될 수도 있다.
또한, 프로그램은 복수의 저장 매체에 나누어 저장될 수도 있으며, 이 때, 복수의 저장 매체의 적어도 일부는 전자 장치의 외부 기기에 위치할 수도 있다.
명령어는, 컴파일러에 의해 만들어지는 것과 같은 기계어 코드뿐만 아니라 인터프리터 등을 사용해서 컴퓨터에 의해서 실행될 수 있는 고급 언어 코드를 포함할 수 있다. 상술한 하드웨어 장치는 다양한 실시예의 동작을 수행하기 위해 하나 이상의 소프트웨어 모듈로서 작동하도록 구성될 수 있으며, 그 역도 마찬가지다.
또한, 이상에서는 본 개시의 바람직한 실시 예에 대하여 도시하고 설명하였지만, 본 개시는 상술한 특정의 실시 예에 한정되지 아니하며, 청구범위에서 청구하는 본 개시의 요지를 벗어남이 없이 당해 개시가 속하는 기술분야에서 통상의 지식을 가진 자에 의해 다양한 변형실시가 가능한 것은 물론이고, 이러한 변형실시들은 본 개시의 기술적 사상이나 전망으로부터 개별적으로 이해되어서는 안될 것이다.

Claims (15)

  1. 다중 운영체제(OS)가 실행되는 전자 장치에 있어서,
    제1 OS와 제2 OS의 가용 메모리 상황에 따라 상기 제1 OS의 메모리를 상기 제2 OS로 전달 및 상기 전달한 메모리를 회수하는 것을 직접 판단하여 상기 제2 OS에 상기 전달 및 회수의 실행을 요청하는 제1 메모리 관리 모듈;
    상기 제1 OS의 메모리 가용 상태 정보를 수집하고, 상기 제2 OS에 요청하여 상기 제2 OS의 메모리 정보를 지정된 수집 주기(interval)에 수집하는 제1 상태 수집 모듈;
    상기 제2 OS가 상기 제1 OS의 요청에 따라 상기 제1 OS의 동적 메모리를 할당하는 메모리 할당 모듈;
    상기 제2 OS의 메모리 가용 상태 정보를 수집하는 제2 상태 수집 모듈; 및
    상기 동적 메모리 할당 정보를 바탕으로, 상기 제1 OS의 메모리를 전달받거나 상기 전달받은 메모리를 상기 제1 메모리로 돌려주어 상기 제2 OS의 메모리를 관리하는 제2 메모리 관리 모듈;을 포함하는 전자장치.
  2. 제1항에 있어서,
    상기 제1 OS 메모리 관리 모듈은,
    상기 제1 OS와 상기 제2 OS의 가용 메모리 상태 정보를 판단하고,
    상기 제2 OS가 메인으로 실행되고, 상기 제1 OS가 서브로 실행될 때, 상기 제1 OS의 가용 메모리를 상기 제2 OS가 사용하도록 상기 메모리 할당 모듈에 전달을 요청하고,
    상기 제1 OS가 메인으로 실행될 때, 제1 OS는 상기 메모리 할당 모듈에 상기 전달한 메모리를 회수 요청하는 전자장치.
  3. 제2항에 있어서,
    상기 제1 메모리 관리 모듈은,
    상기 판단된 가용 메모리 상황에 따라, 상기 제1 OS에서 상기 제2 OS로 메모리를 전달 및 최소 가용 메모리양을 결정하고,
    상기 판단된 가용 메모리 상황 및 상기 최소 가용 메모리 양을 바탕으로, 상기 제1 OS의 메모리를 상기 제2 OS로 전달 및 회수 요청 중 하나를 결정하는 전자장치.
  4. 제3항에 있어서,
    상기 최소 가용 메모리양은 상기 제1 OS의 어플리케이션 실행을 위한 최소 단위의 가용 메모리양으로 상기 제1 OS에 의해 지정될 수 있고,
    상기 지정된 가용 메모리양에 따라, 상기 제1 OS는 상기 제2 OS에 메모리 회수 요청을 할 수 있으며,
    상기 지정된 가용 메모리양은, 상기 어플리케이션의 평균 사용량에 따라 결정되는 전자장치.
  5. 제2항에 있어서,
    상기 전달 또는 회수 결정은,
    상기 제1 OS가 상기 제2 OS로 메모리 전달 또는 회수 여부를 판단하고, 판단 결과에 따라 상기 제2 OS의 상기 메모리 할당 모듈에 요청하는 전자장치.
  6. 제2항에 있어서,
    상기 제1 OS는 복수 개의 제1 OS일 수 있고,
    상기 복수개의 제1 OS는, 각 제1 OS에 설치된 제1 메모리 관리모듈이 분산 컴퓨팅으로 상기 제1 OS의 메모리를 상기 제2 OS로 전달 또는 상기 제1 OS로 회수 여부를 결정하는 전자장치.
  7. 제1항에 있어서,
    상기 수집 주기는, 상기 제1 OS 및 상기 제2 OS의 메모리 부족 상태근접 여부 및 메모리 사용량 변동 여부에 따라 결정될 수 있고,
    상기 제1 OS는,
    상기 제1 OS 및 상기 제2 OS의 메모리 부족 이벤트가 발생 시, 상기 지정된 수집 주기를 기다리지 않고 상기 제1 메모리 관리 모듈을 실행할 수 있는 전자장치.
  8. 제1항에 있어서,
    상기 메모리 할당 모듈은,
    상기 제1 OS의 요청에 따라, 상기 제1 OS의 메모리를 상기 제2 OS로 할당하거나, 상기 제1 OS로 상기 할당된 메모리의 회수를 실행하고,
    상기 제1 OS가 복수 개일 때, 상기 제1 OS의 메모리를 다른 제1 OS로 할당할 수 있는 전자장치.
  9. 제1항에 있어서,
    상기 제2 메모리 상태 수집 모듈은,
    상기 제2 OS의 상태 변화가 발생할 때, 상기 제2 OS의 메모리 가용 상태 정보를 수집하고,
    상기 제1 OS의 상기 정보 요청 시, 상기 제1 OS에 상기 정보를 전달하거나, 또는 상기 제2 OS 메모리 부족시, 상기 제1 OS에 상기 제2 OS의 메모리 부족 상태를 전달하는 전자장치.
  10. 제1항에 있어서,
    상기 제1 OS는 게스트 운영시스템이고, 상기 제1 메모리 관리 모듈 및 상기
    제1 상태 수집 모듈은, 가상 머신의 상기 게스트 운영시스템 내에서 실행되고,
    상기 제2 OS는 호스트 운영시스템이고, 상기 제2 메모리 관리 모듈, 상기 메모리 할당 모듈, 및 상기 제2 상태 수집 모듈은, 상기 호스트 운영시스템 내에서 실행될 수 있는 전자장치.
  11. 다중 운영체제(OS)가 실행되는 전자장치에서 제1 OS 및 제2 OS간 동적 메모리 관리 방법은,
    상기 제1 OS와 상기 제2 OS의 가용 메모리 상황에 따라 상기 제1 OS의 메모리를 상기 제2 OS로 전달 및 상기 전달한 메모리를 회수하는 것을 직접 판단하여 상기 제2 OS에 상기 전달 및 회수의 실행을 요청하는 제1 메모리 관리 단계;
    상기 제1 OS의 메모리 가용 상태 정보를 수집하고, 상기 제2 OS에 요청하여 상기 제2 OS의 메모리 정보를 지정된 수집 주기에 수집하는 제1 상태 수집 단계;
    상기 제2 OS가 상기 제1 OS의 요청에 따라 상기 제1 OS의 동적 메모리를 할당하는 메모리 할당 단계;
    상기 제2 OS의 메모리 가용 상태 정보를 수집하는 제2 상태 수집 단계; 및
    상기 동적 메모리 할당 정보를 바탕으로, 상기 제1 OS의 메모리를 전달받거나 상기 전달받은 메모리를 상기 제1 메모리로 돌려주어 상기 제2 OS의 메모리를 관리하는 제2 메모리 관리 단계;를 포함하는 동적 메모리 관리 방법.
  12. 제11항에 있어서,
    상기 제1 메모리 관리 단계는,
    상기 제1 OS와 상기 제2 OS의 가용 메모리 상태 정보를 판단하고,
    상기 제2 OS가 메인으로 실행되고, 상기 제1 OS가 서브로 실행될 때, 상기 제1 OS의 가용 메모리를 상기 제2 OS가 사용하도록 상기 메모리 할당 모듈에 전달을 요청하고,
    상기 제1 OS가 메인으로 실행될 때, 상기 제1 OS는 상기 메모리 할당 모듈에 상기 전달한 메모리를 회수 요청하는 동적 메모리 관리 방법.
  13. 제12항에 있어서,
    상기 제1 메모리 관리 단계는,
    상기 판단된 가용 메모리 상황에 따라, 상기 제1 OS에서 상기 제2 OS로 메모리를 전달 및 최소 가용 메모리양을 결정하고,
    상기 판단된 가용 메모리 상황 및 상기 최소 메모리 단위를 바탕으로, 상기 제1 OS의 메모리를 상기 제2 OS로 전달 및 회수 회수 요청 중 하나를 결정하는 동적 메모리 관리 방법.
  14. 제13항에 있어서,
    상기 최소 가용 메모리양은, 상기 제1 OS의 어플리케이션 실행을 위한 최소 단위의 가용 메모리양으로 상기 제1 OS에 의해 지정될 수 있고,
    상기 지정된 가용 메모리양에 따라, 상기 제1 OS는 상기 제2 OS에 메모리 회수 요청을 할 수 있으며,
    상기 지정된 가용 메모리양은, 상기 어플리케이션의 평균 사용량에 따라 결정되는 동적 메모리 관리 방법.
  15. 제12항에 있어서,
    상기 전달 또는 회수 결정은,
    상기 제1 OS가 상기 제2 OS로 메모리 전달 또는 회수 여부를 판단하고, 판단 결과에 따라 상기 제2 OS의 상기 메모리 할당 모듈에 요청하는 동적 메모리 관리 방법.
PCT/KR2016/006570 2015-11-11 2016-06-21 멀티 운영시스템을 지닌 전자장치 및 이의 동적 메모리 관리 방법 WO2017082505A1 (ko)

Priority Applications (1)

Application Number Priority Date Filing Date Title
US15/774,356 US10817332B2 (en) 2015-11-11 2016-06-21 Electronic device having multi-operating system and method for managing dynamic memory for same

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
KR1020150158033A KR102513961B1 (ko) 2015-11-11 2015-11-11 멀티 운영시스템을 지닌 전자장치 및 이의 동적 메모리 관리 방법
KR10-2015-0158033 2015-11-11

Publications (1)

Publication Number Publication Date
WO2017082505A1 true WO2017082505A1 (ko) 2017-05-18

Family

ID=58695672

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/KR2016/006570 WO2017082505A1 (ko) 2015-11-11 2016-06-21 멀티 운영시스템을 지닌 전자장치 및 이의 동적 메모리 관리 방법

Country Status (3)

Country Link
US (1) US10817332B2 (ko)
KR (1) KR102513961B1 (ko)
WO (1) WO2017082505A1 (ko)

Families Citing this family (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR102661703B1 (ko) * 2016-12-23 2024-04-29 삼성전자주식회사 전자 장치 및 그의 제어 방법
KR102091409B1 (ko) * 2018-03-09 2020-03-20 삼성전자 주식회사 전자장치 및 그 제어방법
WO2019172622A1 (ko) * 2018-03-09 2019-09-12 삼성전자(주) 전자장치 및 그 제어방법
US20210165673A1 (en) * 2019-12-02 2021-06-03 Microsoft Technology Licensing, Llc Enabling shared graphics and compute hardware acceleration in a virtual environment
US11580019B2 (en) * 2020-04-17 2023-02-14 Microsoft Technology Licensing, Llc Computer memory management in computing devices
KR20220033912A (ko) * 2020-09-10 2022-03-17 삼성전자주식회사 메모리를 관리하기 위한 전자 장치, 전자 장치의 동작 방법, 및 비 일시적 저장 매체

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20090122936A (ko) * 2007-06-27 2009-12-01 인터내셔널 비지네스 머신즈 코포레이션 가상 머신의 메모리를 관리하기 위한 시스템, 방법 및 프로그램
KR20110138888A (ko) * 2010-06-22 2011-12-28 삼성전자주식회사 방송수신장치 및 그의 메모리 관리방법
US20120233435A1 (en) * 2011-03-13 2012-09-13 International Business Machines Corporation Dynamic memory management in a virtualized computing environment
US20130145073A1 (en) * 2011-12-02 2013-06-06 Vmware, Inc. Memory defragmentation in a hosted hypervisor
KR20150097981A (ko) * 2014-02-19 2015-08-27 한국과학기술원 가상화 시스템에서 메모리 조정방법

Family Cites Families (14)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7433951B1 (en) 2000-09-22 2008-10-07 Vmware, Inc. System and method for controlling resource revocation in a multi-guest computer system
JP2006522971A (ja) * 2003-04-09 2006-10-05 ジャルナ エスアー オペレーティングシステム
JP2004318540A (ja) * 2003-04-17 2004-11-11 Hitachi Ltd 性能情報監視装置、方法およびプログラム
KR20070005917A (ko) * 2003-09-30 2007-01-10 쟈루나 에스에이 운영체제
KR20070003765A (ko) * 2003-10-01 2007-01-05 쟈루나 에스에이 운영체제
CA2577493A1 (en) * 2004-08-18 2006-02-23 Jaluna Sa Operating systems
US8146082B2 (en) * 2009-03-25 2012-03-27 Vmware, Inc. Migrating virtual machines configured with pass-through devices
US8935506B1 (en) * 2011-03-31 2015-01-13 The Research Foundation For The State University Of New York MemX: virtualization of cluster-wide memory
JP5742410B2 (ja) * 2011-04-11 2015-07-01 日本電気株式会社 フォールトトレラント計算機システム、フォールトトレラント計算機システムの制御方法、及びフォールトトレラント計算機システムの制御プログラム
DE112012007061B4 (de) * 2012-11-22 2016-09-08 Mitsubishi Electric Corp. Datensammel- und Übertragungsvorrichtung
US8875295B2 (en) * 2013-02-22 2014-10-28 Bitdefender IPR Management Ltd. Memory introspection engine for integrity protection of virtual machines
KR101489870B1 (ko) * 2013-08-19 2015-02-06 성균관대학교산학협력단 가상화 장치 및 그 메모리 관리 방법
US9582223B2 (en) * 2014-04-14 2017-02-28 International Business Machines Corporation Efficient reclamation of pre-allocated direct memory access (DMA) memory
US9841991B2 (en) * 2014-05-12 2017-12-12 Netapp, Inc. Techniques for virtual machine migration

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20090122936A (ko) * 2007-06-27 2009-12-01 인터내셔널 비지네스 머신즈 코포레이션 가상 머신의 메모리를 관리하기 위한 시스템, 방법 및 프로그램
KR20110138888A (ko) * 2010-06-22 2011-12-28 삼성전자주식회사 방송수신장치 및 그의 메모리 관리방법
US20120233435A1 (en) * 2011-03-13 2012-09-13 International Business Machines Corporation Dynamic memory management in a virtualized computing environment
US20130145073A1 (en) * 2011-12-02 2013-06-06 Vmware, Inc. Memory defragmentation in a hosted hypervisor
KR20150097981A (ko) * 2014-02-19 2015-08-27 한국과학기술원 가상화 시스템에서 메모리 조정방법

Also Published As

Publication number Publication date
US10817332B2 (en) 2020-10-27
US20200249969A1 (en) 2020-08-06
KR20170055180A (ko) 2017-05-19
KR102513961B1 (ko) 2023-03-27

Similar Documents

Publication Publication Date Title
WO2017082505A1 (ko) 멀티 운영시스템을 지닌 전자장치 및 이의 동적 메모리 관리 방법
WO2014104634A1 (en) System and method for dynamically expanding virtual cluster and recording medium on which program for executing the method is recorded
CN110865867B (zh) 应用拓扑关系发现的方法、装置和系统
WO2019117593A1 (ko) 컨테이너 기반의 자원 할당을 지원하는 클라우드 컴퓨팅 장치 및 방법
US9558025B2 (en) Inter-board virtualization management for managing hardware resources corresponding to interrupts
US9852008B2 (en) Computer-readable recording medium storing execution information notification program, information processing apparatus, and information processing system
US8856585B2 (en) Hardware failure mitigation
US9507619B2 (en) Virtualizing a host USB adapter
WO2013027910A1 (ko) 클라우드 컴퓨팅 서버 시스템의 가상머신 제어 장치 및 방법
WO2013133621A1 (ko) 이종의 운영체제를 사용하는 가상화 시스템의 전력 관리 방법 및 장치
WO2014142553A1 (ko) 워크 로드에 따라 동적 자원 할당 가능한 상호 연결 패브릭 스위칭 장치 및 방법
WO2014025145A1 (en) Method and apparatus for processing message between processors
US20090150640A1 (en) Balancing Computer Memory Among a Plurality of Logical Partitions On a Computing System
JP2001331333A (ja) 計算機システム及び計算機システムの制御方法
KR20100066458A (ko) 논리적 파티션들 사이의 네트워크 어댑트 리소스 할당
CN102473106A (zh) 虚拟环境中的资源分配
CN111988230B (zh) 虚拟机通信方法、装置、系统及电子设备
US20130067467A1 (en) Resource management in a virtualized environment
CN104539708A (zh) 一种云平台资源的缩容方法、装置与系统
US11435812B1 (en) Efficient utilization of spare datacenter capacity
WO2016003127A1 (ko) 서버/스토리지 관리 시스템
US11595321B2 (en) Cluster capacity management for hyper converged infrastructure updates
US10042790B2 (en) Computer and method with interrupt vector management
WO2014129737A1 (ko) 광고 제공 시스템 및 그 방법, 그리고 이에 적용되는 장치
US10467113B2 (en) Executing programs through a shared NVM pool

Legal Events

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

Ref document number: 16864431

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 16864431

Country of ref document: EP

Kind code of ref document: A1