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

Abstract

A mobile device according to an embodiment disclosed includes a memory; local storage; and a processor, wherein the processor uses the local storage and a communication-connected cloud server as a swap space for pages stored in the memory.

Description

Mobile device and memory management method of a mobile device {Mobile device and management method of mobile device}

Disclosed embodiments relate to a mobile device and a memory management method of the mobile device.

Mobile devices such as smart phones, tablets, or laptops contain computing resources with relatively low performance compared to desktops or servers. Mobile devices require a large amount of memory to simultaneously execute programs such as applications. The size of the memory allocated by the application is larger than the working set, which is the size of frequently used memory. Accordingly, the mobile device can efficiently drive an application using a small-sized memory by managing the memory.

An exemplary embodiment disclosed is to provide a mobile device and a memory management method of the mobile device.

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

According to an embodiment, a method for managing a memory by a mobile device includes: swapping out a page stored in the memory to a local storage of the mobile device or a cloud server connected by communication; and swapping-in the swapped-out page according to the characteristics of the page in which the page fault occurs and the storage location of the page in which the page fault occurs.

1 is a diagram for explaining a swap system according to an embodiment.
2 is a configuration diagram illustrating a mobile device according to an embodiment.
3 is a configuration diagram illustrating a mobile device according to an embodiment.
4 is a diagram for explaining an operation of swapping out a page by a mobile device according to an exemplary embodiment.
5 is a flowchart illustrating an operation of a mobile device according to an exemplary embodiment.
6 is a flowchart illustrating an operation of a mobile device according to an exemplary embodiment.
7 is a diagram for describing an operation of a page swap-in by a mobile device according to an embodiment.
8 is a flowchart illustrating an operation of a page swap-in by a mobile device according to an exemplary embodiment.
9 is a diagram for describing 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 a method of operating a mobile device according to an exemplary embodiment.

1 is a diagram for describing 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 allocating a working set of memory to the memory of the mobile device 100 . When the space to store data in the memory is insufficient, the mobile device 100 swaps out data that has not been used for a long time in the memory. Swapping out refers to moving data from memory to another storage space. For example, when the memory stores data in page units, the mobile device 100 may store a page stored in the memory in a local storage, and store only information indicating a location in which 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 may use a storage space of the cloud server 200 connected through communication as a swap space. The storage space of the mobile device 100 is limited due to size restrictions. Accordingly, the mobile device 100 may swap-out the page to the cloud server 200 and store the page in the cloud server 200 . Although FIG. 1 illustrates that the mobile device 100 uses the cloud server 200 as an example, the mobile device 100 is connected to the mobile device 100 wirelessly or by wire to transmit and receive data. You can use the device's storage space as swap space. For example, the mobile device 100 may use another mobile device, a desktop, a tablet, or the like.

The cloud server 200 swaps the page out or swaps in according to the request of the mobile device 100 . The cloud server 200 includes a sufficient storage space, and when receiving a request to store a page from the mobile device 100 , stores the received page in an internal memory or storage. Also, when receiving a request 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 configuration diagram illustrating a mobile device according to an embodiment. Referring to FIG. 2 , the mobile device 100 includes a memory 110 , a processor 120 , and a local storage 130 . The mobile device 100 may manage the memory 110 by using the cloud server 200 connected through communication. The mobile device 100 may swap-out a page stored in the memory 110 to the local storage 130 or the cloud server 200 . Also, the mobile device 100 may swap-in a page 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. The mobile device 100 allocates a predetermined area to the memory 110 for each application. The mobile device 100 may write and read data generated while executing an application in an area allocated to the memory 110 in units of pages.

The processor 120 manages the memory 110 . The processor 120 manages pages stored in the memory 110 . The processor 120 may swap-out a page that has not been used for a long time among pages stored in the memory 110 to the local storage 130 or the cloud server 200 to secure a storage space in the memory 110 . In addition, when the page requested by the application is not stored in the memory 110 , the processor 120 may check a location in which the requested page is stored and swap the requested page into the memory 110 . . An operation of the processor 120 to swap-out and swap-in a page will be described in detail with reference to the drawings below.

The 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 an operation. In addition, the processor 120 may include a cache or a buffer to store data.

3 is a configuration diagram illustrating a mobile device according to an embodiment.

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

The swap cache 122 temporarily stores prefetched pages. Alternatively, the swap cache 122 is used for synchronization of swap-in and swap-out occurring at the same time.

The swap daemon 123 swaps out pages. When the storage space in the memory 110 is insufficient, the swap daemon 123 may swap out the oldest page among pages stored in the memory 110 .

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

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 being swapped out or swapped in. The swap manager 125 tracks how often pages are swapped out or swapped in and used. The swap manager 125 determines whether to store the page in the local storage 130 or the cloud server 200 based on the tracking result.

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

Page translator 126 processes pages before they are swapped out or swapped in. The page translator 126 may compress or decompress the page. The page translator 126 may use the two pages to generate a delta page. The page translator 126 generates a delta page using logically same pages. For example, the page translator 126 may generate a delta page by performing an XOR operation on logically identical pages. The XOR operation is an operation that outputs 0 if the values are the same and 1 if they are different values. Therefore, if two pages are exactly the same, the delta page values are all 0. If the content of the reference page is 11101010 and the content of the page being swapped out is 11111010, the delta page becomes 00010000. Therefore, the more similar the contents of the pages, the higher the compression ratio. Since the page translator 126 performs swap-out or swap-in using a delta page, network bandwidth can be reduced and battery consumption can be reduced.

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

The compression cache 127 stores compressed pages. Pages stored in the compression cache 127 are evicted in the order of least used oldest. Information on the exported page is acquired through the swap manager 125 .

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

4 is a diagram for explaining an operation of swapping out a page by a mobile device according to an exemplary embodiment.

When the storage space in the memory 110 is insufficient, the swap daemon 123 swaps out the oldest page among pages stored in the memory 110 . Data is stored in the memory 110 in units of pages. The swap daemon 123 outputs a page to be swapped out to the page translator 126 . The pages stored in the memory are divided into an active page list and an inactive page list. Lists are managed by 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 the cloud server 200 .

The swap manager 125 may determine a storage location according to the number of times the compressed page has been 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 has been previously swapped-out or swapped-in is greater than or equal to a threshold value, otherwise it is stored in the cloud server 200 Save.

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

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

1) Once swapped out and unused pages are transmitted 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 being swapped out and swapped out in a clean form, additional page writes are not required, so it is stored in the local storage 130

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

- The third page (Read/write-intensive page with big delta potion) is different 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 that are simultaneously affected by two or more applications, or sensitive pages, and platform pages are preferentially stored in the local storage 130 over other conditions. Since shared pages are allocated to the memory 110 in a copy-on-write (COW) method, they are shared by a plurality of applications until a new page is copied. COW means that when a page is shared, if the page is changed by a certain sharer, other sharers are affected. Therefore, the sharer duplicates the page to be changed, creates the sharer's own page, and then modifies the created page.

The bulk buffer 128 bundles a plurality of pages in consideration of network bandwidth and transmits them to the cloud server 200 . At this time, the bulk buffer 128 preferentially transmits only meta information including the hash value of the page to the cloud server 200, and checks whether the same page is stored in the cloud server 200, Only pages that are not identical are transmitted to the cloud server 200 .

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

In step 501 , the mobile device 100 checks whether 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, etc. in the memory 110 . If the storage space in the memory 110 is insufficient, the generated data cannot be stored. Therefore, when a data storage request occurs, the memory 110 ) to check the storage space.

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

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

In operation 504 , the mobile device 100 removes the mapping of pages with applications. Removing the mapping means deleting information for accessing the memory 110 in which a page is stored, from information used (eg, a page table), and information indicating a swapped-out location (eg, a swap entry). means to record

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

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

In step 507 , the mobile device 100 checks whether the swapped-out previous page exists in the local storage 130 . The swapped-out previous page may be referred to as a parent page or a reference page. In other words, the previous page is logically the same as the current swap-out page. Pages logically identical to the previous page have the same address in the memory 110 and are pages allocated by the same program. When a page is swapped out from the memory 110 , the page is deleted from the memory 110 , and when it is swapped in again, it is written to the memory 110 . At this time, if the swapped-out page and the swapped-in page are not tracked, the mobile device 100 recognizes the swapped-out page and the swapped-in page as different pages. Accordingly, the mobile device 100 may track the swapped-out page and the swapped-in page, and if the address of the page and the program using the page are the same, the two pages are recognized as a page having a parent-child relationship.

In step 508, the mobile device 100 generates a delta page using the page to be swapped out and the previous page. The mobile device 100 may 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 indicates the ratio of the values of 1 among the values of the delta page. If the delta ratio is greater than 1/3, there is no advantage in generating delta pages, so proceed to step 510 , otherwise proceed to step 511 . The mobile device 100 may set the delta ratio to 1/n. Here, n may be a natural number, and the mobile device 100 may determine whether to use delta data based on a set delta ratio.

In 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 greater than 1/3, the previous page cannot serve as a reference page for the page to be swapped out, so the previous page is invalidated.

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

6 is a flowchart illustrating an operation of a mobile device according to an exemplary embodiment. The mobile device 100 may store the page to be swapped out in 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 compression cache 127 . If there is no storage space in the compression cache, proceed to step 602 .

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

In step 603, the mobile device 100 determines whether the extracted page is a frequently used page. 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 . Since the extracted page is a frequently used page, 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 metadata of pages stored in the bulk buffer 128 to the cloud server 200 . Pages are stored in the form of a key-value store that uses the page's unique id and device id as keys and page data as values. Accordingly, the mobile device 100 and the cloud server 200 may swap-in and swap-out pages by using the key. Meta data indicates 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 there is a duplicate page in the cloud server 200 . The mobile device 100 may transmit a request for checking whether there is a duplicate page to the cloud server 200 , and receives a response to the request from the cloud server 200 . The mobile device 100 transmits the 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 verification result to the mobile device 100 . If there is no duplicate page in the cloud server 200 , the process proceeds to step 608 , and if there is, proceeds to step 609 .

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

In step 609 , the mobile device 100 initializes the bulk buffer 128 . Since the mobile device 100 has transmitted all the pages written in the bulk buffer 128 to the cloud server 200 , the bulk buffer 128 is initialized.

7 is a diagram for describing an operation of a page swap-in by a mobile device according to an embodiment. Referring to FIG. 7 , when a page fault occurs, the mobile device 100 may swap-in a page through various paths. Specifically, the mobile device 100 records pages stored in a storage space other than the memory 110 in the memory 110 .

When the application 140 accesses the memory to refer to a page, but there is no page to be referenced in the memory (page missing), the page fault handler 121 is activated. The page fault handler 121 checks the swap cache 122 to determine whether a page that has already been requested for reasons such as prefetching is stored in the swap cache 122 . When there is no requested page in the swap cache 122 , the page fault handler 121 receives information about the requested page from the swap manager 125 and determines a path to receive the requested page.

The page fault handler 121 performs swap-in according to the page type as follows.

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

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

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

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

5) Since the hybrid page is a page in which the original page is stored in the local storage 130 and the delta page is stored in the cloud server 200 , the mobile device 100 includes the local storage 130 and the cloud The original page and the delta page received from the server 200 are combined and swapped in.

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

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

In step 802 , the mobile device 100 determines whether a swapped-out page exists in the swap cache 122 . If there is a swapped-out page in the swap cache 122 , the process proceeds to step 805 , otherwise the process proceeds to step 803 .

In step 803 , the mobile device 100 determines whether a swapped-out page exists in the local storage 130 . If the swapped-out page exists in the local storage 130 , the process proceeds to step 804 , otherwise proceeds to step 806 .

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

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

In step 806, the mobile device 100 determines whether the swapped-out page is a delta page. The mobile device 100 checks whether 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, the flow goes to step 807; otherwise, the flow goes to step 808.

In operation 807 , the mobile device 100 reads the reference page from the local storage 130 .

In step 808 , the mobile device 100 checks whether the swapped-out page exists in the cloud server 200 . If the swapped-out page exists in the cloud server 200 , the process proceeds to step 809 , otherwise proceeds 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 restores the page received from the cloud server 200 .

In operation 810 , the mobile device 100 checks whether a swapped-out page exists in the compression cache 127 or the bulk buffer 128 . If the swapped-out page exists in the compression cache 127 or the bulk buffer 128, the process proceeds to step 805; otherwise, the process proceeds to step 811.

In step 811 , the mobile device 100 returns an error because the swapped-out page cannot be found.

9 is a diagram 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 together 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 swapped-out pages. Content hashing is a hash calculation of the content of a page to generate a hash value of a small size, and when a page is swapped out, only the hash value is transmitted to the cloud server 200 first to check whether a page with the same content already exists in the server It means checking process. Specifically, if there are pages having the same hash value as the hash value of the swapped-out page among the stored pages, the page manager 212 shares the contents of the swapped-out page. For example, in FIG. 9, keyA and keyb refer to pageA, and keyc refers to pageC. The reference to pageA by keyA and keyb indicates that the pages corresponding to keyA and keyB share the data of pageA. keyA and keyb are key information included in the page's metadata, and pageA represents actual data. Since PageA is shared by keyA and keyb, even if a modification request for pgaeA is received, the page manager 212 does not directly modify pageA, but copies pageA and then modifies the copied pageA. The page's metadata includes information such as process id, address, key, and hash, and refers to the content of the page. Accordingly, meta data of several pages may refer to one page at the same time. If the contents of the pages are the same, multiple pages share the same data.

In the page manager 212 , if there are no pages having the same hash value as the hash value of the swapped-out page among the stored pages, the page swapped out to any one storage server 221 of the page pool 220 . save the

The page manager 212 manages the meta data of swapped-out pages, and then uses the meta data for prefetching.

The cloud server 200 may record the same page in the plurality of storage servers 221 . If it is impossible to access any one storage server 221 , the cloud server 200 may access another storage server 221 storing the same page and read the page. Storing the same page in the plurality of storage servers 221 is called replication, and the cloud server 200 may store the same page in at least two or more 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 according to the swap-in request of the mobile device 100 .

When receiving the swap-in request from the mobile device 100 , the request handler 211 outputs the received request to the page manager 212 .

The page manager 212 checks a 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 is possible to check where the requested page is stored through the location information.

Also, the page manager 212 may prefetch similar pages to the mobile device 100 together with the requested page. The page manager 212 classifies pages by process id and manages a list of classified pages. Accordingly, the page manager 212 may transmit a page that has the same process id as the requested page and stored nearby to the mobile device 100 while returning the requested page from the mobile device 100 .

If the storage space of the memory 110 of the mobile device 100 is free before the swap-in request is received, the page manager 212 prefetches a page for a running application before a page fault occurs. can do. For example, the page manager 212 may manage a list in which the order in which pages are swapped out by process id is recorded, and the most recently swapped out pages may be prefetched first.

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

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

In operation 1120 , the mobile device 100 swaps in the swapped-out page according to the characteristics of the page in which the page fault occurs and the storage location of the page in which the page fault occurs.

The device according to the present embodiments includes 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 touch panel, a key, a button, and the like. It may include an interface device and the like. Methods implemented as 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 includes a magnetic storage medium (eg, read-only memory (ROM), random-access memory (RAM), floppy disk, hard disk, etc.) and an optically readable medium (eg, CD-ROM). ) and DVD (Digital Versatile Disc)). The computer-readable recording medium may be distributed among network-connected computer systems, so that the computer-readable code may be stored and executed in a distributed manner. The medium may be readable by a computer, stored in a memory, and executed on a processor.

This embodiment may be represented by functional block configurations and various processing steps. These functional blocks may be implemented in any number of hardware and/or software configurations that perform specific functions. For example, an embodiment may be an integrated circuit configuration, such as memory, processing, logic, look-up table, etc., capable of executing various functions by the control of one or more microprocessors or other control devices. can be hired Similar to how components may be implemented as software programming or software components, this embodiment includes various algorithms implemented in a combination of data structures, processes, routines, or other programming constructs, including C, C++, Java ( Java), assembler, etc. may be implemented in a programming or scripting language. Functional aspects may be implemented in an algorithm running on one or more processors. In addition, the present embodiment may employ the prior art for electronic environment setting, signal processing, and/or data processing. Terms such as “mechanism”, “element”, “means” and “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 association with a processor or the like.

The specific implementations described in this embodiment are examples, and do not limit the technical scope in any way. For brevity of the specification, descriptions of conventional electronic components, control systems, software, and other functional aspects of the systems may be omitted. In addition, the connection or connection members of lines between the components shown in the drawings illustratively represent functional connections and/or physical or circuit connections, and in an actual device, various functional connections, physical connections that are replaceable or additional may be referred to as connections, or circuit connections.

In this specification (especially in the claims), the use of the term “above” and similar referential terms may be used in both the singular and the plural. In addition, when a range is described, individual values within the range are included (unless there is a description to the contrary), and each individual value constituting the range is described in the detailed description. Finally, the steps constituting the method may be performed in an appropriate order unless the order is explicitly stated or there is no description to the contrary. It is not necessarily limited to the order of description of the above steps. The use of all examples or exemplary terms (eg, etc.) is merely for describing the technical idea in detail, and the scope is not limited by the examples or exemplary terms unless limited by the claims. In addition, those skilled in the art will appreciate that various modifications, combinations, and changes can be made in accordance with design conditions and factors within the scope of the appended claims or their equivalents.

100: mobile device
110: memory
120: processor
130: local storage

Claims (15)

A mobile device using a cloud server connected through local storage and communication as a swap space for pages stored in memory,
The mobile device is
the memory;
the local storage; and
at least one processor;
the at least one processor,
identify insufficient storage space in the memory;
identify a first page to be removed from the memory from among the pages stored in the memory based on the insufficient storage space of the memory;
identify a second page swapped out from the memory to the local storage;
generating a third page for obtaining the first page from the second page using the first page and the second page;
determining a page to be swapped out from among the first page or the third page based on the compression ratio of the third page;
swap-out the determined page to the local storage based on a number of swap-outs of the determined page being equal to or greater than a preset threshold;
The mobile device swaps out the determined page to the cloud server based on the determined number of pages swap-out being less than a preset threshold. delete The method of claim 1,
When the reference page logically identical to the page to be swapped out to the cloud server is stored in the local storage, the at least one processor compresses the page to be swapped out and swaps the compressed page to the cloud server- Mobile device characterized in that out. 4. The method of claim 3,
The at least one processor generates a delta page by performing an XOR operation on the page to be swapped out and the reference page, and swaps out the delta page to the cloud server. ◈Claim 5 was abandoned when paying the registration fee.◈ The method of claim 1,
the at least one processor checks whether the same page as the page to be swapped out is stored in the cloud server, and swaps out the page to be swapped out to the cloud server only when the same page is not stored Characterized by a mobile device. ◈Claim 6 was abandoned when paying the registration fee.◈ The method of claim 1,
The at least one processor stores pages to be transmitted to the cloud server in a bulk buffer, and swaps out the pages stored in the bulk buffer in consideration of network bandwidth. ◈Claim 7 was abandoned at the time of payment of the registration fee.◈ The method of claim 1,
and the at least one processor checks a location in which a requested page is stored and a characteristic of the page when a page fault occurs, and swaps the page into the memory. A method for a mobile device to manage memory, the method comprising:
identifying insufficient storage space in the memory;
identifying a first page to be removed from the memory from among the pages stored in the memory based on the insufficient storage space of the memory;
identifying a second page swapped out from the memory to local storage of the mobile device;
generating a third page for obtaining the first page from the second page using the first page and the second page;
determining a page to be swapped out from among the first page or the third page based on the compression ratio of the third page;
swapping out the determined page to the local storage based on the determined number of page swap-outs being equal to or greater than a preset threshold; and
and swapping out the determined page to a cloud server based on the determined number of page swap-outs being less than a preset threshold. delete The method of claim 8, wherein the swap-out comprises:
When a reference page logically identical to a page to be swapped out to the cloud server is stored in the local storage, the page to be swapped out is compressed and the compressed page is swapped out to the cloud server A method for managing memory in a mobile device. The method of claim 10, wherein the swap-out comprises:
The memory management method of a mobile device, characterized in that the page to be swapped out and the reference page are XORed to generate a delta page, and the delta page is swapped out to the cloud server. The method of claim 8, wherein the swap-out comprises:
Checking whether the same page as the page to be swapped out is stored in the cloud server, and swapping out the page to be swapped out to the cloud server only when the same page is not stored How to manage memory. The method of claim 8, wherein the swap-out comprises:
The memory management method of a mobile device, characterized in that the pages to be transmitted to the cloud server are stored in a bulk buffer, and the pages stored in the bulk buffer are swapped out in consideration of network bandwidth. The method of claim 8, wherein the swap-in step comprises:
When a page fault occurs, the memory management method of the mobile device, characterized in that the page is swapped into the memory by checking a location in which a requested page is stored and characteristics of the page. A computer-readable recording medium in which a program for executing the method of any one of claims 8 and 10 to 14 in a computer is recorded.

Images