KR20160068481A - Mobile device and management method of mobile device - Google Patents

Abstract

According to an embodiment of the present invention, a mobile device comprises: a memory; a local storage; and a processor. The processor uses a cloud server, connected to the local storage or communications, as a swap space of pages stored in the memory. The embodiment of the present invention is to provide a mobile device and a management method of the same.

Description

[0001] DESCRIPTION [0002] MEMORY MANAGEMENT OF MOBILE DEVICES AND MOBILE DEVICES [0003]

The disclosed embodiments relate to a method for managing memory of a mobile device and a mobile device.

Mobile devices such as smartphones, tablets or laptops contain relatively low-performance computing resources compared to desktops or servers. Mobile devices require a large amount of memory to run programs such as applications concurrently. The size of the memory allocated by the application is larger than the working set, which is frequently used memory size. Therefore, the mobile device manages the memory and can efficiently operate the application using the small-sized memory.

One disclosed embodiment is to provide a method for managing memory of a mobile device and a mobile device.

A mobile device according to one embodiment includes a memory; Local storage; And a processor, wherein the processor uses a cloud server coupled to the local storage and communication as swap space for pages stored in the memory.

A method for a mobile device to manage a memory, the method comprising: swapping out a page stored in the memory to a cloud server connected to the mobile device's local storage or communication; And swapping in the swapped-out page according to the characteristics of the page where the page fault occurred and the storage location of the page where the page fault occurred.

1 is a view for explaining a swap system according to an embodiment.
2 is a block diagram illustrating a mobile device according to an exemplary embodiment of the present invention.
3 is a block diagram illustrating a mobile device according to an exemplary embodiment of the present invention.
4 is a diagram for explaining an operation in which a mobile device swap-out a page according to an embodiment.
5 is a flowchart for explaining the operation of the mobile device according to an embodiment.
6 is a flowchart illustrating an operation of a mobile device according to an embodiment.
7 is a diagram for explaining an operation in which a mobile device according to an embodiment swaps a page.
8 is a flowchart illustrating an operation of a mobile device according to an exemplary embodiment of the present invention.
9 is a view for explaining a cloud server according to an embodiment.
10 is a diagram for explaining a cloud server according to an embodiment.
11 is a flowchart illustrating an operation method of a mobile device according to an embodiment.

1 is a view for explaining a swap system according to an embodiment. Referring to FIG. 1, the mobile device 100 may use the cloud server 200 as a swap space. Swap is a technique for effectively assigning a working set of memory to the memory of the mobile device 100. [ The mobile device 100 swaps out unused data for a long time in memory if there is insufficient space to store data in the memory. Swap-out indicates moving data from memory to another storage space. For example, when the memory stores data in units of pages, the mobile device 100 may store the page stored in the memory in the local storage, and store only the information indicating the location where the page is stored in the memory. The memory may be a volatile storage medium, and the local storage may be a non-volatile storage medium such as a hard disk.

The mobile device 100 can use the storage space of the cloud server 200 connected by communication as a swap space. The mobile device 100 is limited in storage space due to its size limitation. Thus, the mobile device 100 may swap out the page to the cloud server 200 and store the page in the cloud server 200. [ 1 illustrates that the mobile device 100 uses the cloud server 200. The mobile device 100 is connected to the mobile device 100 in a wireless or wired manner to transmit all electronic data The storage space of the device can be used as a swap space. For example, the mobile device 100 may use another mobile device, and may use a desktop, a tablet, or the like.

The cloud server 200 swaps-in or swaps-in the page upon the request of the mobile device 100. The cloud server 200 includes sufficient storage space, and upon receiving a request to store a page from the mobile device 100, stores the received page in internal memory or storage. In addition, when the cloud server 200 is requested to transmit a page from the mobile device 100, the cloud server 200 transmits the stored page to the mobile device 100.

2 is a block diagram illustrating a mobile device according to an exemplary embodiment of the present invention. 2, the mobile device 100 includes a memory 110, a processor 120, and a local storage 130. The mobile device 100 can manage the memory 110 using the cloud server 200 connected by communication. The mobile device 100 may swap out pages stored in the memory 110 to the local storage 130 or the cloud server 200. [ The mobile device 100 may also swap the pages stored in the local storage 130 or the cloud server 200 to the memory 110.

The memory 110 is a space for storing data when the mobile device 100 executes a program such as an application or the like. The mobile device 100 allocates a predetermined area to each memory 110 in each application. The mobile device 100 can write and read data generated while executing an application in a page unit in an area allocated in the memory 110. [

The processor 120 manages the memory 110. Processor 120 manages the pages stored in memory 110. The processor 120 can swap out a page that is not used for a long time from the page stored in the memory 110 to the local storage 130 or the cloud server 200 to secure the storage space of the memory 110. [ In addition, if the page requested by the application is not stored in the memory 110, the processor 120 may determine where the requested page is stored and may swap the requested page into the memory 110 . The operation of the processor 120 to swap-out and swap pages is described in detail below with reference to the drawings.

Processor 120 drives an operating system (OS). The processor 120 runs an operating system such as a Windows kernel or a Linux kernel to execute an application and manages data stored in the memory 110. [

The processor 120 may include a functional unit or program module that processes data and performs operations. In addition, the processor 120 may store data, including a cache or buffer.

3 is a block diagram illustrating a mobile device according to an exemplary embodiment of the present invention.

The page fault handler 121 processes the page request. The page fault handler 121 returns a requested page to the memory 110 when the requested page is not stored in the memory 110 when the application requests the page to the memory 110. [ A page fault occurs when a program accesses a swapped-out page after the page stored in the memory 110 has been swapped out. The page fault handler 121 processes a page fault because a page fault has occurred due to swapping.

The swap cache 122 temporarily stores prefetched pages. Or the swap cache 122 are used for synchronization for a swap-in, swap-out that occurs at the same time.

The swap daemon 123 swaps the page out. The swap daemon 123 may swap out the oldest page among the pages stored in the memory 110 if the memory 110 lacks storage space.

Prefetch daemon 124 pre-stores the page in memory 110 before a page request is made. A page request occurs when a page fault occurs. However, page faults can be reduced if the device receiving the swap-in request sends in advance the pages that are expected to be used with the swap-in page. Therefore, when a page request is made, the cloud server 200 or the like transmits to the mobile device 100 in advance the pages to be used together with the requested page. The prefetch daemon 124 may save page faults or swap-in requests by storing the pages to be used in memory 110 in the future.

The swap manager 125 manages pages that are swapped-out or swapped-in. For example, the swap manager 125 may track the life cycle of pages that are swapped-out or swapped-in. The swap manager 125 tracks how often pages are swapped-out or swapped-in and used. Based on the tracking result, the swap manager 125 determines whether to store the page in the local storage 130 or in the cloud server 200.

When the page fault occurs, the swap manager 125 checks where the requested page is stored, checks whether a delta page exists for the requested page, and checks whether the requested page is a zero page do.

The page translator 126 processes the page before the page is swapped-out or swapped-in. The page translator 126 may compress or decompress the page. The page translator 126 may generate a delta page using two pages. The page translator 126 generates delta pages using logically the same pages. For example, the page translator 126 may perform XOR operations on logically identical pages to generate a delta page. The XOR operation is an operation of outputting 0 for the same value and outputting 1 for different values. Thus, if the two pages are completely identical, the value of the delta page is all zero. If the content of the reference page is 11101010 and the content of the page being swapped out is 11111010, then the delta page is 00010000. Therefore, the more similar the contents of pages, the higher the compression rate. The page translator 126 may swap-out or swap-in using a delta page, thereby reducing network bandwidth and battery consumption.

The page translator 126 may perform an integrity test of the page. The integrity check means that the restored page is identical to the actual page. Since the mobile device 100 transmits and receives wirelessly compressed data to and from the cloud server 200 after compressing the page, the page translator 126 restores the page after receiving the page, Check if the page is the same.

The compression cache 127 stores compressed pages. Pages stored in the compressed cache 127 are evicted in the order in which they are least recently used. Information about the exported page is obtained through the swap manager 125.

The bulk buffer 128 temporarily stores the pages to be swapped out to the cloud server 200. The bulk buffer 128 may transmit a plurality of pages to the cloud server 200 in consideration of the network bandwidth.

4 is a diagram for explaining an operation in which a mobile device swap-out a page according to an embodiment.

The swap daemon 123 swaps out the oldest page among the pages stored in the memory 110 when the memory 110 lacks storage space. The memory 110 stores data in page units. The swap daemon 123 outputs the page to be swapped out to the page translator 126. Pages stored in memory are divided into an active page list and an inactive page list. Lists are managed with a least-recently-used (LRU) policy.

The page translator 126 compresses the page and outputs the compressed page to the compression cache 127.

The swap manager 125 determines whether to store the compressed page in the local storage 130 or in the cloud server 200. [

The swap manager 125 may determine the storage location according to the number of times the compressed page was previously swapped-out or swapped-in. The swap manager 125 stores the compressed page in the local storage 130 if the number of times the compressed page was previously swapped out or swapped-in is greater than or equal to the threshold value, and otherwise the compressed page is stored in the cloud server 200 .

The swap manager 125 may determine the storage location according to the size of the delta page. The swap manager 125 stores the delta page in the cloud server 200 if the size of the delta page is equal to or larger than the threshold value, and stores it in the local storage 130 otherwise. Since the small size of the delta page means that it is similar to the reference page, it stores the delta page in the local storage 130 where the reference page is stored.

The swap manager 125 may determine the storage location of the page according to the following rules.

One) Once swapped out and not used, the page is sent to the cloud server 200 for the life of the local storage 130

2) Frequently accessed pages

- Since the first page (read-intensive page) is frequently swapped-in after swap-out and is swapped out in a clean form, additional page writing is not required,

- The second page (Read / Write-intensive page with small delta potion) occurs frequently, both sweep-in and sweep-out, but because the size of the delta page is small and only slightly different from the reference page stored in the local storage 130, Stored in storage 130

- The third page (read / write-intensive page with big delta potion) differs from the reference page, and since the size of the delta page is also large, it is stored in the cloud server 200

3) Shared / sensitive pages

Shared pages, sensitive pages, and platform pages that are simultaneously affected by two or more applications are preferentially stored in local storage 130 prior to other conditions. Since the shared pages are allocated to the memory 110 in a copy-on-write (COW) manner, they are shared by a plurality of applications until a new page is copied. COW means that when one page is shared, other sharers are affected if the page is changed by any sharer. Therefore, the sharer replicates the page to be changed and creates the sharper's own page, and then modifies the generated page.

The bulk buffer 128 binds a plurality of pages to the cloud server 200 in consideration of the network bandwidth. At this time, the bulk buffer 128 preferentially transmits only the meta information including the hash value of the page to the cloud server 200, checks whether the same page is stored in the cloud server 200, And transmits only non-identical pages to the cloud server 200.

5 is a flowchart for explaining the operation of the mobile device according to an embodiment. The mobile device 100 may determine and compress the page to be swapped out.

In step 501, the mobile device 100 confirms that the storage space of the memory 110 is insufficient. If the storage space of the memory 110 is insufficient, the process proceeds to step 502. The mobile device 100 stores data generated while executing a program or the like in the memory 110. If the memory 110 does not have enough storage space to store the generated data, ).

At step 502, the mobile device 100 activates the swap daemon 123. The swap daemon 123 swaps some of the pages stored in the memory 110 to another storage space to secure the storage space of the memory 110. [

In step 503, the mobile device 100 checks whether there is a page to be swapped out. If there is a page to be swapped out, the process proceeds to step 504; otherwise, the process proceeds to step 501. The page to be swapped out is stored in the memory 110, but is not used for a certain period of time.

At step 504, the mobile device 100 removes the mapping of the page with the applications. Removing the mapping removes information for accessing the memory 110 in which the page is stored, information (e.g., a swap entry) indicating the swapped-out location in the information (e.g., page table) . ≪ / RTI >

In step 505, the mobile device 100 determines whether the page to be swapped out is a dirty page. A dirty page is a page that has not been swapped out previously, or whose value has been modified. If the page to be swapped out is a dirty page, proceed to step 507;

At step 506, the mobile device 100 removes the page to be swapped out from the memory 110. If the page to be swapped out is not a dirty page, the mobile device 100 does not need to swap out further because a copy of the page to be swapped out is already stored in the swap area.

At step 507, the mobile device 100 determines whether the previous page that has been swapped out is present in the local storage 130. The previous page that has been swapped out may be referred to as a parent page or a reference page. In other words, the previous page is logically the same page as the current page to be swapped out. Pages logically the same as the previous page have the same address in memory 110 and are pages assigned by the same program. When the page is swapped out from the memory 110, the page is deleted from the memory 110 and written back to the memory 110 when it is swapped-in again. At this time, if the page to be swapped out and the page to be swapped are not tracked, the mobile device 100 recognizes the swapped-out page and the swapped-in page as different pages. Thus, the mobile device 100 can track the pages that are swapped out and the pages that are swapped in. If the programs that use the addresses and pages of the page are the same, the two pages are recognized as pages of the parent-child relationship.

At step 508, the mobile device 100 creates a delta page using the page to be swapped out and the previous page. The mobile device 100 can generate a delta page by performing an XOR operation on the current page to be swapped out and the previous page.

In step 509, the mobile device 100 determines whether the delta ratio is 1/3 or more. The delta ratio represents the ratio of one of the values in the delta page. If the delta ratio is 1/3 or more, there is no merit to generate a delta page, so the process proceeds to step 510; otherwise, the process proceeds to step 511. The mobile device 100 may set the delta ratio to 1 / n. Where n may be a natural number and the mobile device 100 may determine whether to use the delta data based on the set delta ratio.

At step 510, the mobile device 100 invalidates the previous page stored in the local storage 130 and removes the delta page. If the delta ratio is 1/3 or more, the previous page can not serve as a reference page for the page to be swapped out, thus invalidating the previous page.

In step 511, the mobile device 100 stores the page to be swapped out in the compression cache 127 after compression. In other words, the mobile device 100 compresses the page to store or swap-out the delta page in the compressed cache 127 and stores it in the compressed cache 127.

6 is a flowchart illustrating an operation of a mobile device according to an embodiment. The mobile device 100 may store the page to be swapped out to the local storage 130 or the cloud server 200. [

In step 601, the mobile device 100 determines whether there is no storage space in the compressed cache 127. [ If there is no storage space in the compressed cache, step 602 is reached.

In step 602, the mobile device 100 determines the page to be evicted in the compression cache 127. For example, the mobile device 100 extracts the oldest page among the pages stored in the compressed cache 127.

In step 603, the mobile device 100 determines whether the extracted page is frequently used. If the extracted page is a frequently used page, the process proceeds to step 604; otherwise, the process proceeds to step 605.

In step 604, the mobile device 100 writes the extracted page to the local storage 130. The extracted page is a frequently used page, so it is stored in the local storage 130 instead of the cloud server 200.

In step 605, the mobile device 100 writes the extracted page to the bulk buffer 128.

In step 606, if there is no storage space in the bulk buffer 128, the mobile device 100 transmits the metadata of the pages stored in the bulk buffer 128 to the cloud server 200. Pages are stored in a key-value store that uses the page's unique id and device id as the key and the page's data as the value. Thus, the mobile device 100 and the cloud server 200 may swap-in or swap out pages using a key. The metadata represents the id of the process using the page, the address of the page, or the unique id of the page.

In step 607, the mobile device 100 checks whether the cloud server 200 has a duplicate page. The mobile device 100 can send a request to the cloud server 200 to check whether there is a duplicate page and receive a response to the request from the cloud server 200. [ The mobile device 100 transmits metadata to the cloud server 200 together with the confirmation request. The cloud server 200 checks whether a page having the same metadata as the received metadata is stored, and transmits the confirmation result to the mobile device 100. [ If there are no duplicated pages in the cloud server 200, the flow advances to step 608, and if it is, the flow advances to step 609.

In step 608, the mobile device 100 transmits to the cloud server 200 pages that do not overlap with pages stored in the cloud server 200. [

In step 609, the mobile device 100 initializes the bulk buffer 128. The mobile device 100 initializes the bulk buffer 128 since it has transmitted all of the pages written to the bulk buffer 128 to the cloud server 200. [

7 is a diagram for explaining an operation in which a mobile device according to an embodiment swaps a page. Referring to FIG. 7, when a page fault occurs, the mobile device 100 may swap pages through various paths. Specifically, the mobile device 100 records the pages stored in the storage space except for the memory 110 in the memory 110. [

The page fault handler 121 is activated when the application 140 accesses the memory to refer to the page but there is no page to be referred to in memory (page missing). The page fault handler 121 checks the swap cache 122 to see if a page already requested is stored in the swap cache 122 for reasons such as prefetching. The page fault handler 121 receives information about the requested page from the swap manager 125 and determines a path for receiving the requested page when the swap cache 122 does not have a requested page.

The page fault handler 121 swaps in according to the page type as follows.

One) Since the zero page is a page that is NULL when the page is swapped out, the mobile device 100 immediately recovers the page without unnecessary swap-in or swap-out.

2) Since the cache page is a page stored in the compression cache 127, the mobile device 100 restores and swaps in the page.

3) Since the buffered page is a page stored in the bulk buffer 128, the mobile device 100 swaps in via the local storage 130.

4) Since the remote page is a page stored in the cloud server 200, the mobile device 100 sends a page request to the cloud server 200 and swaps-in from the cloud server 200.

5) The hybrid page is a page where the original page is stored in the local storage 130 and the delta page is stored in the cloud server 200 so that the mobile device 100 can access the local storage 130, The original page received from the server 200 and the delta page are combined and swapped in.

8 is a flowchart illustrating an operation of a mobile device according to an exemplary embodiment of the present invention. Referring to FIG. 8, the mobile device 100 swaps in a page according to the characteristics of the page.

At step 801, the mobile device 100 determines whether a page fault has occurred due to swapping. If a page fault has occurred due to the swap, the flow advances to step 802.

At step 802, the mobile device 100 determines whether there is a page that has been swapped out to the swap cache 122. If there is a swapped-out page in the swap cache 122, the flow advances to step 805; otherwise, the flow advances to step 803.

At step 803, the mobile device 100 determines whether the swapped-out pager exists in the local storage 130. [ If the swapped-out pager exists in local storage 130, proceed to step 804, otherwise proceed to step 806.

At step 804, the mobile device 100 swaps-in the page from the local storage 130.

At step 805, the mobile device 100 recovers and swaps in the page. The mobile device 100 restores the compressed page and recovers the page using the reference and delta pages.

At step 806, the mobile device 100 determines whether the swapped-out page is a delta page. The mobile device 100 checks to see if a page requiring swap-in has been swapped out in the form of a delta page when it was previously swapped out. If the swapped-out page is a delta page, proceed to step 807, otherwise proceed to step 808. [

At step 807, the mobile device 100 reads a reference page from the local storage 130.

At step 808, the mobile device 100 checks if the swapped-out page is present in the cloud server 200. [ If the swapped-out page exists in the cloud server 200, the flow advances to step 809; otherwise, the flow advances to step 810.

In step 809, the mobile device 100 requests the cloud server 200 to read the swapped-out page. The mobile device 100 recovers the page received from the cloud server 200.

In step 810, the mobile device 100 checks if there is a page that has been swapped out to the compression cache 127 or the bulk buffer 128. If there is a page that has been swapped out to the compression cache 127 or the bulk buffer 128, the flow advances to step 805; otherwise, the flow advances to step 811.

In step 811, the mobile device 100 returns an error because it can not find the swapped-out page.

9 is a view for explaining a cloud server according to an embodiment. Referring to FIG. 9, the cloud server 200 may store the swapped-out page in the storage server 221 according to the swap-out request of the mobile device 100. The cloud server 200 includes a master server 210 and a page pool 220. The master server 210 includes a request handler 211 and a page manager 212 and the page pool 220 includes a plurality of storage servers 221.

The request handler 211 receives a swap-out request from the mobile device 100. Specifically, the request handler 211 receives a page to be written with a page-write request. The request handler 211 outputs the received request to the page manager 212.

The page manager 212 manages duplicated pages based on content hashing of the swapped-out pages. Content hashing is a method of hashing a content of a page to generate a small hash value. When a page is swapped out, only the hash value is transmitted to the cloud server 200, It means the process of checking. Specifically, the page manager 212 shares the contents of the swapped-out page if the pages have pages having the same hash value as the hash value of the swapped-out page among the stored pages. For example, in FIG. 9, keyA and keyb refer to pageA, and keyc refers to pageC. When keyA and keyb refer to pageA, it means that the page corresponding to keyA and keyB share data of pageA. keyA and keyb are the key information included in the page metadata, and pageA is the actual data. Because PageA is shared by keyA and keyb, even if a modification request for pgaeA is received, page manager 212 does not directly modify pageA, but copies pageA and modifies copied pageA. The metadata of the page includes information such as process id, address, key, hash, and the contents of the page. Thus, multiple pages of metadata can refer to a single page at the same time. If the contents of the page are the same, multiple pages share the same data.

The page manager 212 determines whether the pages having the same hash value as the hash value of the swapped-out page among the stored pages are stored in the storage server 221 of any one of the page pools 220, / RTI >

The page manager 212 manages the metadata of the swapped-out pages, and then uses the metadata for the prefetch.

The cloud server 200 can record the same page to a plurality of storage servers 221. [ If one of the storage servers 221 can not be accessed, the cloud server 200 can access the other storage server 221 storing the same page to read the page. Storing the same page in a plurality of storage servers 221 is referred to as replication, and the cloud server 200 can store the same page in at least two storage servers 221.

10 is a diagram for explaining a cloud server according to an embodiment. Referring to FIG. 10, the cloud server 200 may return a page to the mobile device 100 in response to a swap-in request of the mobile device 100.

The request handler 211 receives the swap-in request from the mobile device 100 and outputs the received request to the page manager 212.

The page manager 212 confirms the location where the requested page is stored, and returns the page stored in the storage server 221 to the mobile device 100. Since the page manager 212 manages the location information of the pages, it can check where the requested page is stored through the location information.

The page manager 212 may also prefetch similar pages to the mobile device 100 along with the requested page. The page manager 212 classifies pages into process IDs and manages a list of classified pages. Accordingly, the page manager 212 may return the requested page from the mobile device 100, and may transmit the neighboring page to the mobile device 100 together with the same process id as the requested page.

The page manager 212 may prefetch a page for an application that is running before a page fault occurs if there is room in the memory 110 of the mobile device 100 before the swap- can do. For example, the page manager 212 may manage a list of the order in which pages were swapped out by process id, and may prefetch the most recently swapped-out pages.

11 is a flowchart illustrating an operation method of a mobile device according to an embodiment.

At step 1110, the mobile device 100 swaps out pages stored in the memory 110 to the local storage 130 or to the cloud server 200 connected in communication.

In step 1120, the mobile device 100 swaps in the swapped out page according to the nature of the page on which the page fault occurred and the storage location of the page on which the page fault occurred.

An apparatus according to the present embodiments may include a processor, a memory for storing and executing program data, a permanent storage such as a disk drive, a communication port for communicating with an external device, a user such as a touch panel, a key, Interface devices, and the like. Methods implemented with software modules or algorithms may be stored on a computer readable recording medium as computer readable codes or program instructions executable on the processor. Here, the computer-readable recording medium may be a magnetic storage medium such as a read-only memory (ROM), a random-access memory (RAM), a floppy disk, a hard disk, ), And a DVD (Digital Versatile Disc). The computer-readable recording medium may be distributed over networked computer systems so that computer readable code can be stored and executed in a distributed manner. The medium is readable by a computer, stored in a memory, and executable on a processor.

This embodiment may be represented by functional block configurations and various processing steps. These functional blocks may be implemented in a wide variety of hardware and / or software configurations that perform particular functions. For example, embodiments may include integrated circuit components such as memory, processing, logic, look-up tables, etc., that may perform various functions by control of one or more microprocessors or other control devices Can be employed. Similar to how components may be implemented with software programming or software components, the present embodiments may be implemented in a variety of ways, including C, C ++, Java (" Java), an assembler, and the like. Functional aspects may be implemented with algorithms running on one or more processors. In addition, the present embodiment can employ conventional techniques for electronic environment setting, signal processing, and / or data processing. Terms such as "mechanism", "element", "means", "configuration" may be used broadly and are not limited to mechanical and physical configurations. The term may include the meaning of a series of routines of software in conjunction with a processor or the like.

The specific implementations described in this embodiment are illustrative and do not in any way limit the scope of the invention. For brevity of description, descriptions of conventional electronic configurations, control systems, software, and other functional aspects of such systems may be omitted. Also, the connections or connecting members of the lines between the components shown in the figures are illustrative of functional connections and / or physical or circuit connections, which may be replaced or additionally provided by a variety of functional connections, physical Connection, or circuit connections.

In this specification (particularly in the claims), the use of the terms " above " and similar indication words may refer to both singular and plural. In addition, when a range is described, it includes the individual values belonging to the above range (unless there is a description to the contrary), and the individual values constituting the above range are described in the detailed description. Finally, if there is no explicit description or contradiction to the steps constituting the method, the steps may be performed in an appropriate order. It is not necessarily limited to the description order of the above steps. The use of all examples or exemplary terms (e. G., The like) is merely intended to be illustrative of technical ideas and is not to be limited in scope by the examples or the illustrative terminology, except as by the appended claims. It will also be appreciated by those skilled in the art that various modifications, combinations, and alterations may be made depending on design criteria and factors within the scope of the appended claims or equivalents thereof.

100: Mobile device
110: Memory
120: Processor
130: Local Storage

Claims (15)

Memory;
Local storage; And
A processor,
The processor comprising:
And uses the cloud server connected to the local storage and communication as a swap space of pages stored in the memory. The method according to claim 1,
Wherein the processor is configured to swap out the page to the local storage or the cloud server based on the characteristics of the page, the number of times the page has been swapped in or swapped out, and the compression rate of the page to be swapped out. The method according to claim 1,
The processor may compress the page to be swapped out and swap out the compressed page to the cloud server if the local storage has stored logically the same reference page as the page to be swapped out to the cloud server A mobile device characterized by. The method of claim 3,
Wherein the processor generates a delta page by XORing the page to be swapped out and the reference page and swapping out the delta page to the cloud server. The method according to claim 1,
Wherein the processor verifies whether the same page as the page to be swapped out is stored in the cloud server and swap out the page to be swapped out to the cloud server only if the same page is not stored Mobile device. The method according to claim 1,
Wherein the processor stores pages to be transmitted to the cloud server in a bulk buffer and swaps out pages stored in the bulk buffer in consideration of network bandwidth. The method according to claim 1,
Wherein the processor is configured to swap-in the page to the memory when a page fault occurs by checking the location where the requested page is stored and the characteristics of the page. In a method for a mobile device to manage memory,
Swapping out a page stored in the memory to a cloud server connected to the mobile device's local storage or communication; And
Swapping in the swapped-out page according to a property of a page faulted page and a storage location of a page faulted page. 9. The method of claim 8, wherein the swap-
Wherein the page is swapped out to the local storage or the cloud server based on the characteristics of the page, the number of times the page has been swapped in or swapped out, and the compression rate of the page to be swapped out. . 9. The method of claim 8, wherein the swap-
And compressing the page to be swapped out and swapping out the compressed page to the cloud server when the reference page logically identical to the page to be swapped out to the cloud server is stored in the local storage. A method for managing memory in a mobile device. 10. The method of claim 9, wherein the swap-
Generating a delta page by XORing the page to be swapped out and the reference page, and swapping out the delta page to the cloud server. 9. The method of claim 8, wherein the swap-
And swap-out the page to be swapped out to the cloud server only if the same page as the page to be swapped out is stored in the cloud server and the same page is not stored. How to manage memory. 9. The method of claim 8, wherein the swap-
Storing pages to be transmitted to the cloud server in a bulk buffer, and swapping out pages stored in the bulk buffer in consideration of a network bandwidth. 9. The method of claim 8, wherein the swap-
And swap-in the page to the memory by checking the location where the requested page is stored and the characteristics of the page when a page fault occurs. A computer-readable recording medium storing a program for causing a computer to execute the method according to any one of claims 8 to 14.

Images