A memory management unit (MMU) for accessing borrowed memory

Abstract

Systems, methods, and apparatus are described for accelerating access to borrowed memory via a network connection. For example, a memory management unit (MMU) of a computing device can be configured to connect to both random access memory via a memory bus and to a computer network via a communication device. The computing device can borrow an amount of memory from a remote device via a network connection using the communication device; and an application running in the computing device can use virtual memory addresses mapped to the borrowed memory. When a virtual address mapped to the borrowed memory is used, the MMU translates the virtual address to a physical address and instructs the communication device to access the borrowed memory.

Description

[0001] Related Applications

[0002] This application claims priority to U.S. Patent Application Serial No. 16 / 424,420, filed May 28, 2019, and titled “MEMORY MANAGEMENT UNIT (MMU) FOR ACCESSING BORROWED MEMORY,” the entire disclosure of which is hereby incorporated by reference herein. TECHNICAL FIELD

[0003] At least some embodiments disclosed herein relate to memory services provided by an operating system. BACKGROUND

[0004] In some computer systems, an operating system allows an application program to use virtual addresses of memory to store data in or retrieve data from memory components of one or more memory subsystems of the computer system. The operating system defines a mapping between virtual memory addresses and physical memory addresses of one or more memory subsystems connected to a central processing unit (CPU) and / or a graphics processing unit (GPU) and / or a system on a chip (SoC) of the computer system. The mapping can be defined using page tables. A page table entry specifies a mapping between a set of virtual memory addresses of a virtual memory page and a corresponding set of physical memory addresses of a physical memory page. Page tables can be used to implement memory accesses requested by virtual memory addresses by translating the virtual memory addresses to corresponding physical memory addresses of the memory subsystem.

[0005] A computer processor can have a memory management unit (MMU) configured to perform translations of virtual memory addresses to physical memory addresses according to page tables defined by an operating system. The memory management unit (MMU) can have a translation lookaside buffer (TLB) configured to cache recently used page table entries. The memory management unit (MMU) can perform other memory related tasks, such as cache control and / or memory protection.

[0006] Generally, a virtual address space of memory in a computer can be divided into pages of a predetermined size. A virtual memory page is represented by a set of virtual memory addresses; the virtual memory addresses can be mapped to physical memory addresses of a physical memory page in a memory subsystem; a page table entry defines a mapping address between a virtual memory page and a physical memory page.

[0007] In some computer systems, an operating system can use paging techniques to access pages of data in a storage device or memory device via pages of memory in a memory module. At different instances in time, the same page of memory in the memory module can be used as a proxy to access a different page of memory in the storage or memory device or another storage or memory device in the computer system.

[0008] Remote direct memory access (RDMA) is a technology that allows direct memory access from one computer to another without involving either of the operating systems of the computers involved (e.g., after executing an operating system to negotiate and set up memory resources for RDMA operations). Prior to an RDMA operation (e.g., a read or write), a command is executed to establish a memory mapping between the two computers via one or more networking devices. When an application running on a computer performs an RDMA operation, application data is delivered directly across the computer network, reducing latency and enabling fast data transfer. RDMA uses a network adapter to transfer data to or from application memory, eliminating the need to copy data between application memory and a data buffer in the operating system. BRIEF DESCRIPTION OF DRAWINGS

[0009] Embodiments are illustrated by way of example, and not by way of limitation, in the figures of the accompanying drawings in which like reference numerals refer to similar elements.

[0010] Figure 1 A system is shown in which a computing device or server computer can borrow memory from and / or lend memory to another computing device and / or another server computer.

[0011] Figure 2 Borrower and lender devices implementing an inter-operating system memory service via a communication network are illustrated according to one embodiment.

[0012] Figure 3 Techniques using borrowed memory are illustrated according to one embodiment.

[0013] Figure 4 Another use of physical memory regions to facilitate access to different borrowed memory regions is illustrated according to one embodiment.

[0014] Figure 5 Another use of physical memory regions to facilitate access to different borrowed memory regions is illustrated according to one embodiment.

[0015] Figure 6 A borrower-lender memory hierarchy in a computing system is illustrated.

[0016] Figure 7 A method of implementing an inter-operating system memory service via a communication network connection is shown.

[0017] Figure 8 A method of service borrowing memory pages is shown, according to one embodiment.

[0018] Figure 9 A borrower device with memory regions having different criticality levels is shown, based on which network traffic for memory-as-a-service can be throttled.

[0019] Figure 10 A criticality level of a memory region in a memory map is labeled, according to one embodiment.

[0020] Figure 11 A method of identifying a criticality level of a memory region is shown, according to one embodiment.

[0021] Figure 12 A method of throttling network communications for memory-as-a-service is shown, according to one embodiment.

[0022] Figures 13 to 15 Hardware acceleration configurations to access borrowed memory are shown, according to some embodiments.

[0023] Figure 16 and 17 Hardware acceleration configurations to provide access to lent memory are shown, according to some embodiments.

[0024] Figure 18 A method to accelerate access to borrowed memory via a memory management unit is shown, according to one embodiment. DETAILED DESCRIPTION

[0025] At least some embodiments disclosed herein provide techniques for inter-operating system memory service via a communication network connection, such that a borrower device can extend its memory capacity by using a communication link and memory of a lender device. The operating system of the borrower device and / or the lender device can be configured to seamlessly bridge the gap over the communication link, such that an application running on the borrower device can use its local memory indistinguishably from the borrowed memory. The local memory is physically installed in the borrower device, and the borrowed memory is physically installed in the lender device, which is connected to the borrower device via a communication connection.

[0026] Optionally, a portion of the borrowed memory and / or the local memory in the borrower device can be lent to another device via a computer network. The borrower device can have multiple lender devices. Thus, a borrower-lender device hierarchy can be formed over a hierarchy of communication links between the devices.

[0027] The operating system of the borrower device can use a virtual-to-physical memory mapping to bridge the disparity between local memory and borrowed memory. For example, the operating system of the borrower device can manipulate a page table entry (PTE) in response to a determined miss in the borrower device's translation lookaside buffer (TLB) that can cause a page fault to use a portion of the borrower device's local memory as an aperture, proxy, and / or cache when accessing borrowed memory via the communication link. Cache coherency between the lender and borrower devices can be relaxed for improved bandwidth usage. Since the disparity between local memory and borrowed memory regions is shielded from applications running on the borrower device by the operating system of the borrower device, applications running on the borrower device can byte access borrowed memory in the same manner as accessing local random access memory configured in the borrower device.

[0028] Memory services of an operating system can be used to construct multiple tiers of byte-addressable memory in a computer system under a unified address space shared by multiple operating systems via incoherent communication links. For example, a wearable computing device can borrow memory from a mobile computing device via a personal area network or local area network. The wearable computing device can be a smart watch, a motion tracking device, or smart glasses, and the mobile computing device can be a smart phone, a touchpad computer, or a notebook computer, among others. The wearable computing device and / or the mobile computing device can borrow memory from a computing appliance via a local area network. For example, the computing appliance can be a mini server, a desktop computer, a memory appliance, or a storage appliance, among others. The mobile computing device and / or the computing appliance can borrow memory from a server computer or a server farm via the Internet and / or via cloud computing.

[0029] In a multi-level hierarchy of lender-borrower of memory resources, each subsequent higher level device (e.g., mobile computing device, computing appliance, server computer, or server farm) can use its memory capacity to augment the memory capacity of lower level devices (e.g., wearable computing device, mobile computing device, computing appliance) and / or devices of the same level as needed. IoT devices will constitute the environment, e.g., construction materials (concrete walls, roads, etc.). It is possible that low density but highly bulky inexpensive memory technology will allow integration of low density memory (and computation) in the construction at very low cost. Thus, we will have some'memory substance' (or possibly computation substance) as part of the environment that any device can use.

[0030] Optionally, depending on the availability of certain devices and / or network connections, some levels in the hierarchy can be skipped. For example, a wearable computing device can borrow memory from a computing device without going through a mobile computing device; and a mobile computing device can borrow memory from a server computer or server farm via the Internet without going through a computing device in a local area network.

[0031] At the device and cloud level, memory resources can be provided as a utility with Memory-as-a-Service (MaaS). Such an arrangement can provide vast persistent memory capacity and memory resources to low-level computing devices, such as wearable computing devices, mobile computing devices, and / or Internet of Things computing devices, on an as-needed basis. Applications running on low-level computing devices can use the memory service provided by the operating system to use borrowed memory in a transparent manner, as if the borrowed memory were part of the local memory of the borrowing device. Thus, no special programming is needed in the applications to use borrowed memory.

[0032] Applications running on the borrowing device can use the borrowed memory to persistently store data, and thus eliminate or reduce the need for operations to store data via a file system. For example, the lending device / server can provide persistent random access memory or storage capacity to provide memory resources to the borrowing device and manage the persistence and / or redundancy of data stored in the provided memory resources, such that the borrowed memory can be treated as a virtual non-volatile random access memory in the borrowing device.

[0033] Optionally, the memory provided as a service can include semantics for memory page sharing between the client / borrower, locking mechanisms, timeout mechanisms, etc.

[0034] As an example, a phone can obtain 8 terabytes (TB) of observable memory from a memory device acting as a lender device as a borrower device via a wireless local area network (WLAN) (e.g., facilitated via a home Wi-Fi access point). The 8 TB of memory is observable to applications running under the phone's operating system in the same manner as applications running on a phone with 8 TB of local memory. Alternatively, the phone can obtain 8 TB of observable memory from a server or cloud computing infrastructure configured as a lender device via a cellular communication network. Optionally, the phone can borrow a portion of the 8 TB of observable memory from the memory device and a portion of the 8 TB of observable memory from the server or cloud computing infrastructure. The 8 TB of observable memory is effectively available to the phone's operating system in the phone such that applications running on the phone can use virtual / remote memory even though the phone can have only 8 megabytes (MB) of physical local memory. The borrowed 8 TB of memory consumes the phone's memory capacity beyond 8 TB; and to applications running on the phone using the borrowed memory, the phone's memory capacity appears to be the same as a phone with more than 8 TB of local random access memory.

[0035] Since the borrower device typically does not immediately use borrowed memory when it is borrowed, the lender device does not have to prevent the allocation of lent memory to the borrowing device when the memory is borrowed. The lender device can implement thin provisioning of memory (e.g., thin-provisioned memory) and incrementally allocate memory in response to the borrower device using increased amounts of borrowed memory.

[0036] An application running under the operating system of the borrower device can read and write to memory pages borrowed from the lender device as needed. Physical page allocation in the lender device and / or corresponding allocation in the borrower device can be configured to perform in response to write operations on the pages. A portion of the local memory of the borrower device can be configured as a cache, proxy, and / or slot for accessing borrowed pages. When an application running on the borrower device accesses a virtual page, the operating system of the borrower device can migrate the contents of the accessed virtual page to local memory. When a local memory page is not accessed for a period of time and / or will be used to host the contents of another page, the operating system of the borrower device can evict or migrate the contents of the virtual page in local memory to borrowed memory on the lender device. Optionally, the operating system of the borrower device can use a portion of the local random access memory of the borrower device as a fast buffer for critical data and use borrowed memory physically residing in a remote lender device to hold less critical data. When needed, less critical data and / or less frequently used data can be migrated to the local random access memory of the borrower device.

[0037] In general, the lender device for a lower level device in the hierarchy can itself be a higher level borrower device in the borrower-lender device hierarchy. For example, a phone that is a borrower device can borrow 8 TB of memory from a memory device that is a lender device. The memory device that is a borrower device can borrow 4 TB of memory from a server, and combine the 4 TB of memory borrowed from the server with 4 TB of its local memory into 8 TB of memory lent to the phone. In some implementations, the 4 TB of memory borrowed from the server can be identified to the phone so that when the connection between the phone and the device is unavailable, the phone can use an alternative connection to the server to continue using the 4 TB of memory without going through the memory device. However, the alternative connection can be slower than the connection to the memory device because the device can be closer to the phone than the remote server.

[0038] The operating system of the lender device and the operating system of the borrower device communicate with each other to facilitate seamless memory access across the communication link between the lender device and the borrower device. Thus, physical memory does not have to be pre-allocated in the lender device before an application running on the borrower device begins using the memory. As the footprint of the application running on the borrower device grows, page eviction traffic and lender device memory availability determine the size of the borrowed memory usage. Eliminating the requirement for pre-allocated physical memory in the lender device for the application (e.g., required in the case of RDMA protocol) removes the need for specific programming (e.g., Message Passing Interface (MPI) via RDMA) and allows the application to run in different configurations of devices in its original code, again with all the benefits of scaling the application capacity laterally, as in the case of RDMA, etc.

[0039] In general, for a particular borrower device, the lender device can be configured to operate in a passive mode or an active mode. For different borrower devices, the lender device can operate in different modes.

[0040] In the passive mode, the operating system of the lender device observes memory pages that are cached or migrated by the operating system of the borrower device via the link, and modifies its own page table entries corresponding to these pages accordingly. The observation of the page movement performed by the lender operating system can be performed, for example, by bus snooping or hardware monitoring.

[0041] The operating system of the borrower device is configured to maintain a page table for the local memory of the borrower device and the borrowed memory physically residing in the lender device. In general, when a borrowed memory page is accessed by an application running on the borrower device, the contents of the page can or can not be currently stored in a local memory page of the borrower device.

[0042] A page fault occurs when a borrower device accesses a page that does not exist in the local memory of the borrower device. For our purposes, we consider page faults to occur in two cases: 1) the page accessed does not exist at all; and 2) the page accessed exists, but is not in local memory.

[0043] If the page does not exist, it was never written or read. There is no page table entry (PTE) for the page. This is the first access to the page. If a read operation is performed on this page, no actual page has to be allocated. Some operating systems (e.g., Linux) can provide a fake page filled with zeros, since the page is never written and thus contains no data. Thus, a read operation performed on such a page results in zeros. In this case, the OS executes the handler for this page fault: a TLB miss causes a page walk, which determines that a read operation was performed on a page without a PTE. Thus, the mapping to the zero page is returned.

[0044] If a write operation is performed on the page for the first time, the write operation is a real fault. A real fault causes a new PTE and page allocation in local memory. An example of a page fault handler for this case: a TLB miss causes a page walk, which determines that a write operation was performed on a page without a PTE. Thus, the operating system allocates a new page, creates a PTE, and installs the PTE in the page table. After the PTE is cached in the TLB, the fault is resolved.

[0045] When a page fault occurs in accessing a borrowed page and the contents of the page are not currently in the local memory of the borrower device (e.g., after the contents of the borrowed page have been migrated / evicted to the lender device), the operating system of the borrower device can communicate with the lender device via a communication link between the borrower device and the lender device to retrieve or migrate the contents of the borrowed page.

[0046] Cache operations can be performed in conjunction with the handling of the two cases discussed above. For example, the lender device can keep a copy of the page. If the borrower device does not further modify the page (e.g., only read operations are performed on the page), the copy can be useful. In this case, no eviction is needed, since a real copy of the page already exists on the lender device. Similarly, the borrower device can perform speculative eviction of the page when the communication link between the borrower device and the lender device is not in use.

[0047] Optionally, the lender device and / or the borrower device can be configured with firmware / hardware that accelerates the operation of migrating contents between the lender device and the borrower device.

[0048] Optionally, the operating system of the lender device can be configured to maintain and operate its own page table and associated set of resources, e.g., page table walkers, translation lookaside buffers (TLBs), content addressable memories (CAMs), lookup tables, etc.

[0049] The operating system of the lender device monitors memory access requests from any of the borrower devices that borrow memory from the lender device. It can be configured to provide semantics of page sharing (e.g., atomic, lock, semaphore, flag, timeout, etc.) among the borrower devices. Thus, the address space of the borrowed memory is unified among the borrower devices according to the page table in the lender device. Distributed applications can take advantage of the unified address space by sharing the borrowed memory through the lender device and different instance applications running on different borrower devices.

[0050] Optionally, the lender device can be configured to accept requests from the borrower devices to produce computational results on certain regions of the memory lent to the borrower devices. Thus, the lender device not only provides memory resources, but also computational power for processing data in the memory lent to the borrower devices.

[0051] The memory services provided by the operating systems of the borrower devices and the lender device allow applications running on the borrower devices to address the borrowed memory at byte granularity, with faults resolved at page granularity.

[0052] The operating system of the borrower device can evict or migrate pages from local memory to the lender device via the communication link between the borrower device and the lender device. The operating system of the borrower device can identify pages to evict or migrate from the local random access memory of the borrower device to its borrowed memory based on infrequent usage of the page and / or based on the page being less recently used than other pages or based on criticality or any other possible measurable system parameter. The operating system of the borrower device can decide to evict or migrate a borrowed page to free local memory for other uses, e.g., new local page allocation or migration of pages from the lender device. As a result of this approach, the current page owner (borrower or lender) has a true copy of the page. Other devices can still cache the page if it has not been modified since the owner released it. For example, when a borrower gets a page from a lender, the lender no longer has the page. However, the lender can not delete the page copy but keep it: if the page is not to be modified after eviction, it will not be necessary to transfer it back to the lender via the link. What if the lender also wants to modify it or provide it to other borrowers? In this case, all writes will have to happen on the lender device to consolidate these write requests from different borrowers.

[0053] To evict or migrate a page, the operating system of the borrower device transfers the contents of the page to the lender device, causing the lender device to store the page in memory of the lender device. The operating system of the borrower device can then update the page table to indicate that the page is now in the lender device and not in the local memory of the borrower device.

[0054] In the active mode, the operating system of the lender device can be configured to monitor the page table on the borrower device, identify unused pages, and reapply the unused pages for other memory users.

[0055] The interaction between the lender device and the borrower device can be implemented via virtualization, allowing the lender device to monitor the page table usage in the borrower device.

[0056] For example, the operating system of the borrower device can be partially virtualized for operation in the operating system of the lender device. Some of the memory management code / subroutines of the operating system of the borrower device can be configured via virtualization to run on the lender device and / or as part of the operating system of the lender device. In this implementation, the operating system of the borrower device can extend a memory access request to the operating system of the lender device to execute this subroutine, which can be hardware / firmware accelerated at the operating system level of the lender device.

[0057] For example, the operating system of the lender device can generate virtual memory devices and provide the virtual memory devices to the borrower device. The borrower device can request virtual memory devices as needed and make the virtual memory devices available to service the memory resource needs of applications running on the borrower device.

[0058] In some cases, if an application running on the borrower device can tolerate or accept the latency caused by the communication link between the borrower device and the lender device, the borrowed page can be accessed directly via the communication link without migrating the entire page to the lender. In other implementations, the content migration can be configured at the sub-page level, and only the portion of the page that is being accessed and / or predicted to be accessed is migrated. Optionally, the operating system can use remote direct memory access (RDMA) techniques when implementing direct memory access. Optionally, this direct memory access can be implemented at the memory controller and / or memory management unit, and thus avoids the standard RDMA protocol and its overhead.

[0059] In some implementations, the operating system of the borrower device is configured to dynamically adjust the physical location of virtual memory pages. The pages of virtual memory are designated by the virtual memory addresses of the pages. The virtual memory pages can initially be located in the local memory of the borrower device, subsequently moved to memory borrowed by the lender device to the borrower device, and subsequently moved to another local page of the borrower device.

[0060] To migrate a virtual page from a lender device to a borrower device, the borrower device extracts the contents of the page from the lender device, stores the contents in its local memory, and updates the relevant page table to establish a mapping between the local physical page and the virtual page. Once the virtual page is migrated to the borrower device, the lender device can release the physical memory previously used for the virtual page and / or erase the data stored there. Optionally, the operating system of the lender device can retain the page previously used for the virtual page and maintain its contents as a backup copy of the virtual page.

[0061] In the opposite direction, the operating system of the borrower device can migrate a virtual page from the borrower device to the lender device. For example, the operating system of the borrower device can request allocation of a borrowed page in the lender device and transmit the contents of the virtual page for storage in the borrowed memory on the lender device. Once the contents of the virtual page are stored on the lender device, the operating system of the borrower device can update its page table for the virtual page to identify a mapping between the virtual page and its physical location in the borrowed memory to complete the migration of the page to the lender device. After the migration of the virtual page, the local memory previously used to host the virtual page can be used to host another virtual page. In this implementation, it is not necessary to statically map a predetermined portion of the virtual memory or virtual memory address space to borrowed memory in the lender device.

[0062] Furthermore, a virtual page does not have to be hosted in a predetermined lender device. For example, the operating system of the borrower device can migrate a virtual page from a first lender device to the borrower device and then migrate the virtual page from the borrower device to a second lender device. In some cases, the operating system of the borrower device can request migration of a virtual page from a first lender device to a second lender device without downloading the contents of the page to the borrower device and then uploading this content to the second lender device.

[0063] Using a memory-as-a-service (MaaS) technique, a mobile device vendor can sell a mobile device with terabytes of memory capacity at the operating system level, which will be backed by emerging memory on a lender device that includes a cloud computing infrastructure. For example, an application in a smart phone configured with 128 MB of local memory can access 64 TB of random access memory when the phone is connected to a computer network or the Internet or a local memory device or any other device that implements the MaaS concept described herein.

[0064] Figure 1 A system is shown in which a computing device or server computer can borrow memory from and / or lend memory to another computing device and / or another server computer.

[0065] Figure 1 The computing devices (101 and 103) and server computers (105 and 107) are illustrated as examples of borrower devices and lender devices connected via a computer network and / or the Internet (109), which can include a cellular communication network, such as a fifth generation cellular network.

[0066] Each of the computing devices (101 and 103) and server computers (105 and 107) can borrow memory from and / or lend memory to another device. Each of the computing devices (101 and 103) and server computers (105 and 107) can have one or more communication devices (e.g., 117, 137, 157, and 177) to establish one or more communication links with each other or another computing device or server computer in the system. Each of the computing devices (101 and 103) and server computers (105 and 107) can have one or more processors (e.g., 115, 135, 155, and 175) configured to execute instructions, such as instructions of an operating system (e.g., 113, 133, 153, and 173) and applications or programs running under the operating system.

[0067] Each of the computing devices (101 and 103) and server computers (105 and 107) can have a local random access memory (e.g., 111, 131, 151, and 171) coupled (e.g., via a memory bus) to the respective processor (e.g., 115, 135, 155, and 175).

[0068] In some examples, device A (101) or device B (103) can be a wearable computing device, an Internet of Things computing device, a mobile computing device, etc.

[0069] In some examples, server P (105) or server Q (107) can be a microserver, a personal computer, a memory device, a storage device, a network storage device, a server computer, a server farm, etc.

[0070] In one example, device A (101) can connect to device B (103), server P (105), and / or server Q (107) using a wired connection, a wireless personal area network (WPAN), a wireless local area network (WLAN), and / or a wireless wide area network (WWAN).

[0071] In another example, device B (103) can connect to server P (105) and / or server Q (107) using a wired connection, a wireless local area network (WLAN), and / or a wireless wide area network (WWAN).

[0072] In another example, server P (105) can connect to server Q (107) using a wired connection, a local area network, a wireless local area network (WLAN), a wireless wide area network (WWAN), and / or the Internet.

[0073] Server P (105) can borrow memory from server Q (107), and lend the borrowed memory and / or local memory to devices (101 and 103) (and / or similar devices). Device B (103) can borrow memory from server P (105) and / or server Q (107) and lend the borrowed memory and / or local memory to device A (101) (and / or similar devices).

[0074] In general, a computing device can lend memory to one or more borrower devices, and borrow memory from one or more lender devices.

[0075] The operating systems (113, 133, 157, and 173) are configured to provide memory services to applications and programs so that the applications and programs can use virtual memory without being aware of its physical allocation, so that this virtual memory can be partially allocated in borrowed memory and partially allocated in local memory (111, 131, 151, and 171). The operating systems and supporting hardware take the burden from the applications and programs to manage virtual memory allocation, which provides a convenience to the applications and programs that do not have to have special code segments or designated instructions designed to handle the differences between local memory and borrowed memory allocation.

[0076] In one example, a portion of the local memory (171) of server Q (107) is borrowed to server P (105). Server P (105) borrows a portion of its borrowed memory and / or a portion of its local memory (151) to device B (103), which in turn borrows a portion of its borrowed memory and / or a portion of its local memory (131) to device A (101). Thus, the virtual memory allocated by the operating system (113) to an application running on the processor (115) of device A (101) can reside partially in the local memory (111) of device A (101), partially in the local memory (131) of device B (103), partially in the local memory (151) of server P (105), and / or partially in the local memory (171) of server Q (107). The operating systems (113, 133, 157, and 173) are configured to cooperate with one another to provide memory services and / or physical allocation of virtual memory used by applications among the local memories (e.g., 111, 131, 151, and / or 171) of the various devices such that an application programmed to run on device A and its local memory (101) can also run unmodified, with its virtual memory partially allocated in borrowed memory (131, 151, and / or 171) borrowed to device A (101) by device B (103), server P (105), and / or server Q (107).

[0077] Figure 2 The borrower device (201) and the lender device (203) implementing inter- operating system memory services via a communication network connection, such as a wired or wireless connection (205) via a local area network, a wide area network, and / or a cellular communication network (e.g., a fifth generation cellular network).

[0078] In Figure 2 , the borrower device (201) borrows memory from the lender device (203); and the lender device (203) lends memory (202) to the borrower device (201). For example, the borrower device (201) can be device A (101), device B (103), server P (105) in the system of Figure 1 ; and the lender device (203) can be device B (103) or server P (105) in the system of Figure 1 . Furthermore, lender device functionality can be implemented in the borrower device (201) enabling it to lend memory to another device. Similarly, borrower device functionality can be implemented in the lender device (203) enabling it to borrow memory from another device.

[0079] InFigure 2 In particular embodiments, the borrower device (201) has a communication device (217), one or more processors (215) with a memory management unit (MMU) (216), and local random access memory (211). The processors (215) and local memory (211) can be in separate computer chips and / or formed on separate integrated circuit dies in some embodiments, and can be packaged in the same computer chip and / or formed on the same integrated circuit die (e.g., in a system on a chip (SoC)) in other embodiments.

[0080] The operating system (213) of the borrower device (201) includes a memory services module (209) configured to maintain a memory map (207). The memory map (207) identifies mappings between virtual memory and physical memory, where the physical memory can be partly in local memory (211) in the borrower device (201) and partly in the lent memory (202) in the lender device (203). The operating system (213) provides virtual memory services for one or more applications (e.g., 212) running on the borrower device (201). A processor (215) can run an application (212) by executing instructions of the application code (212). Application memory read and write instructions can use virtual memory. The memory management unit (MMU) (216) translates virtual memory addresses to physical memory addresses according to the memory map (207).

[0081] When the borrower device (201) borrows memory from the lender device (203), the borrowed memory (204) is effectively in the borrower device (201) and physically in the lender device (203) as the lent memory (202) in the local random access memory (231). Optionally, the lender device (203) can configure a portion or all of the lent memory (202) in the storage device (232) that is coupled to the processor (235) of the lender device (203) via a peripheral bus and / or device controller. For example, the operating system (233) of the lender device (203) can allocate a portion of its memory resources as virtual memory to the operating system (213) of the borrower device (201) in a manner similar to how it allocates memory resources as virtual memory to applications (e.g., 234) running on the lender device (203). Thus, the borrowed memory (204) used by the operating system (213) of the borrower device (201) can be in the unified virtual memory address space as the virtual memory used by the applications (234) and / or borrowed memory used by other borrowers of the lender device (203). Alternatively, the operating system (233) of the lender device (203) can create a virtual memory component for the borrowed memory (204); and the operating system (213) of the borrower device (201) can access the virtual memory component in the borrower device (201). A virtual memory controller for the virtual memory component can be implemented in the operating system (213) to access the virtual memory component that is accessible by the borrower device (201). The MMU 216 can implement a hardware block to accelerate the virtual memory controller and, by doing so, improve the speed of virtual memory component access.

[0082] In some instances, the borrowed memory (204) is implicit such that it cannot be distinguished from the rest of the virtual memory of the applications running on the borrower device 201. The distinction only arises when translating a virtual page address into a physical address by reading the memory map 207, and after the translation, the physical address appears to be in the lent memory 202. In other instances, the operating system (213) stores an explicit identification of the portion of virtual memory that belongs to the borrowed memory (204) as provided by the lender device (203). In all cases, the operating system 213 configures the memory map (207) to access the lender device (203) to read and write from and to the virtual memory that is physically in the lent memory (202) in the lender device (203) or in the borrowed memory (204) in the borrower device (201) after migration to the device.

[0083] Memory mapping (207) can be implemented via page tables. A portion of the page tables are cached in a memory management unit (MMU) (216) so that when an instruction executing in the processor (215) accesses a virtual address defined in the portion of the page tables cached in the memory management unit (MMU) (216), the memory management unit (MMU) (216) translates the virtual address to a physical address. A successful address translation allows the processor (215) to proceed with the memory access without the need to execute code of the operating system (213).

[0084] When the memory management unit (MMU) (216) is unable to successfully translate a virtual memory address using the page tables cached in the memory management unit (MMU) (216), a page table entry cache miss is generated, which causes the processor (215) to execute instructions of the memory service (209) of the operating system (213) to resolve this cache miss. In some embodiments, the MMU contains hardware IP architected to resolve page table entry cache misses in the cache of the MMU (216). This IP as part of the MMU extracts the required page table entry from the page tables stored in the physical memory 211. If the required entry does not exist or it exists but it translates the virtual page address to an address in the physical borrowed memory 202, a page fault is generated for this page. This fault can be resolved by the MMU 216 and the communication device 217 directly in hardware. Alternatively, this fault can be resolved by the operating system 213 and the memory service 209 in software assisted by the hardware blocks: MMU 216, processor 215, communication device 217.

[0085] When the memory service (209) of the operating system (213) or the MMU 216 determines that the virtual memory address being accessed is located in the borrowed memory (204), the memory service (209) or the MMU 216 can allocate a physical page of the local physical memory 211, communicate with the lender device (203) via the communication devices 217 and 237 and the computer network connection 205 to migrate a page of the borrowed memory (204) from the physical borrowed memory 202 to the physical local memory 211, generate a page table entry mapping the virtual page to the allocated local physical page, and load the page table entry into the memory management unit (MMU) (216). Thus, prior to the page fault, the virtual page of the borrowed memory (204) is physically located in the borrowed memory (202) in the lender device (203). After the processing of the page fault, the virtual page is located in the local memory (211). The contents of the page in the borrowed memory 202 of the lender device 203 can still be saved for future use and other purposes.

[0086] When there are no free local pages available for migration, the memory service (209) can evict a selected virtual page currently in local memory (211) to the borrowed memory (202). When a selected virtual page is evicted to the lender device (203), the memory service (209) communicates with the lender device (203) to transfer the contents of the virtual page from local memory (211) to borrowed memory (202) and to update the memory map (207). After evicting a virtual page from local memory (211), the space in local memory (211) for the evicted virtual page can be freed.

[0087] For example, the memory service (209) can be configured to evict the least frequently used virtual pages or the least recently used virtual pages.

[0088] In Figure 2 The lender device (203) has a communication device (237), one or more processors (235) with a memory management unit (MMU) (236), and local random access memory (231). Optionally, the lender device (203) includes one or more storage devices (232) connected to the processor(s) (235) via a peripheral bus and / or a computer network. For example, the storage device(s) (232) can be solid state drives (SSDs) or hard disk drives (HDs).

[0089] The operating system (233) of the lender device (203) includes a memory service module (229) configured to maintain a memory map (227). The memory map (227) identifies the mapping between virtual memory and physical memory. The memory map can be stored in memory 231 or dedicated to its storage, e.g., a content addressable memory or a dedicated cache. The operating system (233) serves one or more applications (234) running on the lender device (203) with virtual memory in a similar manner as the borrower device (201) serves its applications (212).

[0090] Optionally, the lender device (203) provides the lent memory (202) to the borrower device (201) in a unified virtual memory space. The memory service (209) of the borrower device (201) uses the borrowed memory (204) in the same manner as an application (234) uses virtual memory provided by the memory service (229). For example, the memory service (229) of the lender device (203) can allocate virtual memory to an application (234) running on the lender device (203) and allocate the virtual memory as borrowed memory (204) used by the memory service (209) of the borrower device (201) as if the memory service (209) were an application running on the lender device. Thus, applications (234) running on the lender device (203) and the borrower device (201) (and other devices borrowing memory from the lender device (203)) can operate in a unified virtual address space. Cooperative computing can be configured based on the unified virtual address space. Further, when the lender device (203) borrows memory from another device / server (e.g., 105 or 107), the borrowed memory can also be provided in the unified virtual address space. The unified address space can facilitate data sharing and cooperative computing between computing devices.

[0091] The memory service (229) of the lender device (203) can maintain a memory map (227) that includes a mapping between virtual addresses of the lent memory (202) and physical addresses of the lent memory (202) that correspond to the borrowed memory (204) accessed by the borrowing device (201). For example, a page table entry of a virtual page identified by the borrower device (201) when the borrowed page is accessed can be loaded into a memory management unit (MMU) (236) to facilitate translation between an address of the virtual page and a physical address of the lent memory (202) for a processor of the lender device (203) to perform computations on behalf of the borrower device (201). Optionally, the lender device (203) can include hardware similar to the memory management unit (236) to facilitate optimized and / or accelerated data transfer between the lender device (203) and the borrower device (201) using the memory map (227) that identifies a mapping between the borrowed memory (204) as known by the borrower device (201) and the lent memory (202) physically accessible in the lender device (203).

[0092] Figure 3 Techniques for implementing borrowed memory are described in accordance with one embodiment. For example, Figure 3 Techniques can be implemented in the borrower device (201) described in Figure 2 Techniques can be implemented in the borrower device (201) described in

[0093] Figure 3 illustrating a memory (211), a memory management unit (MMU) (216) configured to access the memory (211) using physical addresses (e.g., 257), and a memory map (207) defining mappings between virtual address regions (e.g., 261, 263, 265...) and address regions to which the virtual memory regions are mapped, such as physical address regions (e.g., 281, 283...) and borrowed memory regions (e.g., 273, 275...).

[0094] For example, a borrowed memory address region (e.g., 273,..., 275) can be configured to identify a virtual address region assigned by the lender device (203) as memory provided / lent to the borrower device (201).

[0095] For example, virtual address region A (261) is associated with physical address region (281) in the memory map (207) to indicate that the region of virtual memory is currently directly mapped to a corresponding region of local physical memory (211).

[0096] For example, virtual address region B (263) is associated with borrowed memory address region X (273) and physical address region S (283) in the memory map (207) to indicate that virtual address region B (263) is mapped to borrowed memory address region X (273) and physically resides in physical address region S (283). Thus, access to virtual address region B (263) can be satisfied by accessing physical address region S (283) in local memory (211). Virtual address region C (265) is associated with borrowed memory address region Y (275) in the memory map (207) and is not associated with any physical address region in the memory map (207). Thus, to access virtual address region C (265), the borrower device needs to communicate with the lender device.

[0097] The contents of physical address region S (283) can be evicted to the lender device to free up physical address region S (283). Once physical address region S (283) is freed up, it can be used to physically place another borrowed memory address region, such as borrowed memory address region Y (275). Once the contents of borrowed memory address region Y (275) are migrated from the lender device to the borrower device to physical address region S (283), physical address region S (283) can be used to provide access to virtual address region C (265) mapped to unified address space and physically located in physical address region S (283) of the borrower device, as illustrated in Figure 4 .

[0098] InFigure 5 In particular embodiments, a memory management unit MMU (e.g., similar to 216 as described in Figure 3 In particular embodiments, a memory management unit MMU (e.g., similar to 216 as described in Figure 3 In particular embodiments, a memory management unit MMU (e.g., similar to 216 as described in When a processor (215) of the borrower device (201) executes an instruction that uses a virtual address (255), the TLB (251) uses the virtual-to-physical memory mapping (253) to translate the virtual address (255) to a physical address (257); and the memory management unit (MMU) (216) can use the physical address (257) to access a memory page (259) in the memory (211) (e.g., over a memory bus).

[0099] The virtual-to-physical memory mapping (253) loaded in the TLB (251) is typically a portion of the memory mapping (207) managed by the operating system (213) of the borrower device (201). When a processor (215) of the borrower device (201) executes an instruction that uses a virtual address not covered in the virtual-to-physical memory mapping (253) in the TLB (251), the memory management unit (MMU) (216) can cause the processor (215) to execute the operating system (213) programmed to replace a portion of the virtual-to-physical memory mapping (253) in the TLB (251) so that the updated virtual-to-physical memory mapping (253) in the TLB (251) includes data for translating a virtual address (e.g., 255) to a physical address (e.g., 257).

[0100] The memory management unit (MMU) (216) is typically configured to access the memory (211) via a memory bus coupled between the memory management unit (MMU) (216) of the borrower device (201) and the local memory (211) of the borrower device (201). When a virtual address (255) initially lies in a virtual address region (e.g., 265) mapped to a borrowed memory address region (e.g., 275), the operating system (213) can migrate the contents of this region from the lent memory of the lending device to a physical address region (e.g., 283) in the memory (211), and update the virtual-to-physical memory mapping (253) in the TLB (251) to allow the virtual address (255) to be translated directly to a physical address (257) corresponding to the virtual address (255) without translating it to the borrowed memory address region (e.g., 275).

[0101] In some embodiments, the memory management unit (MMU) (216) is further configured to access the borrowed memory (204) using the communication device (217) via the computer network connection (e.g., 205) without explicit migration. In this case, the operating system (213) does not have to migrate the contents of the virtual address region (e.g., 265). The physical address (257) of the borrowed memory (204) can include information for the communication device (217) to access the memory page (260) in the lent memory (202) in the lender device (203). The use of the physical address (257) and memory access requests via the communication device (217) can be handled in the lender device (203) via its operating system (233). Alternatively, the communication device (237) and / or memory management unit (MMS) (236) can be configured to handle such access requests (e.g., for reading or writing) to the lent memory (202) without performing the operating system (233) (e.g., based on virtual-to-physical memory mappings cached in the TLB of the MMS (236) of the lender device (203) or hardware acceleration components configured in the lender device (203) to perform similar operations).

[0102] The virtual-to-physical memory mappings (253) can be implemented in the form of page table entries.

[0103] Figure 6 A lender-borrower memory hierarchy in a computing system is illustrated.

[0104] In Figure 6 , the lender device (203) can borrow memory from one or more lender servers (245) in a similar manner as the borrower device (201) borrows memory from the lender device (203) in Figure 2 . The lender device (203) pools at least some of its local physical memory (e.g., 231) illustrated in Figure 2 and / or some of its borrowed memory from lender servers (e.g., 245) as available memory (239) to lend to the borrower device (201). One or more borrower devices (201) borrow memory from the lender device (203).

[0105] A typical borrower memory (204) may have multiple borrower memory regions (295, 297, ..., 299) and multiple local memory regions (291, 293, ...). The borrower memory regions (295, 297, ..., 299) in the borrower device (201) can be accessed via migration from the lender device's borrowed memory to the borrower device's (291, 293, ...) local memory regions. When a borrower memory region (295, 297, ..., 299) is not used in the borrower device (201), it can be evicted back to the lender device (203), such as... Figure 4 and Figure 5 As explained in the text.

[0106] Similarly, the lender device (203) may host the area (e.g., 299) lent to the borrower device (201) in its local storage or in local storage borrowed from the lender server (245).

[0107] Generally, more than one lender device (203) can be used to provide memory services to the borrower device (201); and more than one lender server (245) can be configured in the hierarchy.

[0108] Optionally, the memory provided as a service in the hierarchy (e.g., 295, 297, ..., 299) is configured in a unified virtual address space. Therefore, the borrowing device (201), the lending device (203), and the lending server (245) can collaboratively process data in the memory by referring to virtual addresses in the unified virtual address space.

[0109] For example, Figure 6 The borrowing device (201) in the middle can be Figure 1 Device A (101) or device B (103) in the system.

[0110] For example, Figure 6 The lender device (203) in the middle can be Figure 1 Device B (103) or server P (105) in the system.

[0111] For example, Figure 6 The lender server (245) in the middle can be Figure 1 The system contains servers P(105) or Q(107).

[0112] Figure 7 This demonstrates a method for implementing inter-operating system memory services via a communication network connection. For example, Figure 7 The method can be found Figure 1 Implemented in the system, with Figure 2 The borrower-lender configuration and / orFigure 6 the borrower-lender memory hierarchy described in

[0113] At block 301, a communication connection (205) is established from a borrower device (201) to a lender device (203).

[0114] At block 303, the borrower device (201) communicates with the lender device (203) to borrow an amount of memory from the lender device (203). The lender device (203) can allocate the lent memory (203) borrowed by the borrower device (201) as borrowed memory (204) that can be used by the virtual memory borrowed memory (204). With the borrowed / lent memory, the devices (201 and 203) establish a configuration in which the processor of the borrower device (201) can read and / or write into the borrowed memory (204) / lent memory (202). In some cases, the lent memory (202) itself is borrowed memory from another lender device (e.g., 245).

[0115] At block 305, the operating system (213) of the borrower device (201) extends the virtual / logical address space of the borrower device (201) to cover the borrowed memory (204). Applications (e.g., 212) running on the processor (215) of the borrower device (201) can use virtual addresses in the space without needing to distinguish between the borrowed memory (204) and the local memory (211).

[0116] At block 307, the operating system (213) of the borrower device (201) generates a memory map (207) (e.g., in the form of a page table) that maps the extended portion of the logical address space to the borrowed memory (204).

[0117] At block 309, the operating system (213) of the borrower device (201) allocates the extended portion of the logical address space to an application (212).

[0118] At block 311, the operating system (213) of the borrower device (201) services access to the borrowed memory (212) via access to a portion of the physical memory (211) of the borrower device (201).

[0119] Figure 8 A method of servicing borrowed memory pages is shown in accordance with one embodiment. For example, Figure 8 The method of Figure 1 may be implemented in the system of Figure 2 with the borrower-lender configuration described in Figure 6 and / or the borrower-lender memory hierarchy described in Figure 8The method of FIG. 1 can be used to implement Figure 7 the block 311 of the method of FIG. 1.

[0120] At block 331, the borrower device (201) reserves a page of the borrower device's (201) physical memory (211) for the borrowed memory page (204).

[0121] At block 333, the processor of the borrower device (201) accesses a virtual memory address (255) corresponding to a memory page (260) in the borrowed memory (204). The borrowed memory page (204) can be physically in the lent memory (202) of the lender device (203).

[0122] At block 335, the memory management unit (MMU) (216) of the borrower device (201) determines that there is no page table entry in the translation lookaside buffer (TLB) (251) available to convert the virtual memory address (255) to a local physical memory address. This determination (e.g., TLB miss) causes the borrower device (201) to run its operating system (213) to search for a page table entry in the memory map.

[0123] At block 337, the operating system (213) running on the borrower device (201) identifies a page table entry in the memory map that converts a virtual memory address of a page to a borrowed memory address of the page.

[0124] At block 339, the operating system (213) running on the borrower device (201) communicates with the lender device and migrates the physical contents of the borrowed page with the borrowed memory address to local memory and places the contents at an available physical address of the local memory. When there is not enough local memory for the page migration of the borrowed page from the lender device to the borrower device, borrowed page evictions of different borrowed pages from the borrower device to the lender device can need to be performed.

[0125] At block 341, the operating system (213) running on the borrower device (201) generates a page table entry that maps the virtual address (e.g., 255) of the borrowed page to a physical address (257) in the local memory.

[0126] At block 343, the operating system (213) running on the borrower device (201) loads the page table entry into the translation lookaside buffer (TLB) (251), which allows the processor to continue accessing the virtual memory address (255) using the translated physical memory address (257).

[0127] In some cases, the computer network connection (205) between the borrower device (201) and the lender device (203) has limited and / or reduced communication bandwidth. The borrower device (201) can throttle network traffic / bandwidth allocated to different memory regions based on criticality of the memory regions.

[0128] For example, pages of the borrowed memory (204) can be tagged with a criticality indicator based on a category of content stored in the memory, a priority level of an application using the borrowed memory, and / or a data criticality level suggested by the application. When the connectivity bandwidth between the borrower device (201) and the lender device (203) is reduced, by allocating less communication bandwidth for fetching, backing up, evicting, and / or migrating these pages, the least critical pages can be configured to be less accessible. Given the reduced connectivity bandwidth between the borrower device (201) and the lender device (203), access to the least critical pages can be slowed down and / or temporarily cut off.

[0129] Operations to terminate memory can be prepared via stopping or pausing an application that is attempting to load from memory. During that time, the application can not make forward progress. When the application is cut off from the borrowed memory it is accessing, it is possible to perform a graceful degradation. The application can be made aware that load or store operations can cause a pause; and a completely different programming paradigm can be used. For example, each memory access can be wrapped in a try-catch exception wrapper. However, this approach has a considerable cost. In addition, the application can be programmed to handle such exceptions slowly. For example, the application can keep some context open and manage the context related to the aborted load / store operations, informing the data movement infrastructure whether the load / store ultimately still needs to be serviced.

[0130] When borrowed memory pages are throttled according to criticality, applications running on the borrowed memory (204) can still degrade slowly without catastrophic failure, and with less reachable / available content to degrade the functionality.

[0131] For example, a media library can prioritize its content based on frequency of use, history of use, and / or predicted use. The priority can be used to determine the criticality of borrowed memory pages storing the content. Thus, access to less critical content in the borrowed memory can be limited and / or cut off with reduced impact on the availability of the media library.

[0132] Figure 9A borrower device (201) that exhibits memory regions with different criticality levels (or priorities) can throttle network traffic for memory as a service based on the criticality levels (or priorities). For example, the borrower device (201) can Figure 2 implemented and / or can borrow from the hierarchy described in Figure 6 implemented and / or can borrow from the hierarchy described in Figure 1 implemented and / or can borrow from the system described in

[0133] In Figure 9 In one embodiment, the memory regions (295, 297, 299) in the borrowed memory (204) can be tagged with criticality levels (401, 403, 405) respectively. The criticality levels (401, 403, 405) order the relative priorities among the memory regions (295, 297, 299). Network bandwidth for communication between the borrower device (201) and its lender device (e.g., 203) can be allocated according to the criticality levels (401, 403, 405).

[0134] For example, when multiple regions (e.g., 295, 297) need to be migrated from the lender device (203) to the borrower device (201), the regions (e.g., 295, 297) can be migrated in an order according to their criticality levels (e.g., 401, 403). In this arrangement, repeated requests for memory regions of high criticality levels can indefinitely delay access to memory regions of low criticality.

[0135] Alternatively, bandwidth can be shared among multiple regions (e.g., 295, 297) of different criticality levels. For example, the amount of data traffic allowed on the network connection (205) for different regions in a given time period can be allocated according to a ratio based on the criticality levels of the memory regions. Thus, it will take longer to fetch the contents of a memory page of low criticality level than a memory page of high criticality level. However, the fetching of low criticality pages will not be completely blocked by the fetching of high criticality pages. Furthermore, the ratio can be adjusted based on the overall available bandwidth so that the performance of accessing high criticality pages can be reduced less than low criticality pages when the overall available bandwidth is reduced. Thus, the user experience of applications running in the borrower device can be optimized via selectively reducing the speed of access for less critical aspects.

[0136] In Figure 9In some embodiments, the contents of memory regions (e.g., 291,..., 293) in local memory (211) can also be tagged with criticality levels (e.g., 407,..., 409). The criticality levels (e.g., 407,..., 409) can be used to schedule the predictive eviction or migration of less critical contents to borrowed memory (204) in anticipation of a significant reduction in overall available bandwidth.

[0137] For example, in a particular model of bandwidth sharing at sub-page granularity, link-level bandwidth management capabilities or forced chunking on the link can be used. This implementation can lead to potentially inefficient non-throttling situations. Alternatively, when the granularity of management is a page (rather than a sub-page), the rate at which pages are fetched can be slow, rather than the actual time it takes to fetch a single page. With certain implementations, fetching the contents of a memory page of a low criticality level can take longer than fetching the contents of a memory page of a high criticality level. In other implementations, the duration of time taken to fetch a low criticality page can remain substantially constant, but the rate at which groups of low criticality pages can be fetched can be slowed relative to groups of high criticality pages.

[0138] For example, in some cases, the borrower device (201) borrows memory from several lender devices (e.g., 103, 105, and / or 107). For example, the borrower device (201) can instruct one lender (e.g., 105 or 107) to transfer or copy memory pages borrowed to the borrower device (201) directly to another lender (e.g., 103 or 105). Alternatively, the borrower device (201) can migrate memory pages from one lender (e.g., 105 or 107) to local memory, and then evict the pages to another lender (e.g., 103 or 105).

[0139] Figure 10 An illustration of tagging memory regions with criticality levels (or priorities) in a memory map is described according to one embodiment. For example, Figure 10 The memory map of Figure 9 may be used to implement criticality tagging in

[0140] . Figure 10 In Figure 3 , 4 or 5, virtual memory address regions (261, 263, 265...) can be mapped to physical address regions (282, 283) and borrowed memory address regions (273, 275...) in a similar manner. For example, the memory map (207) can be specified in the form of a page table.

[0141] Additionally, for each of the virtual address regions (261, 263, 265...), the memory map (207) can include a criticality level (e.g., 411, 413, or 415). The criticality level (e.g., 411, 413, or 415) can be used to determine that sharing of bandwidth of a virtual address region (e.g., 261, 263, or 265) can be used to transfer data between the borrower device (201) and the lender device (203).

[0142] Figure 11 A method of identifying criticality levels / priorities of memory regions is described in accordance with one embodiment. For example, Figure 11 The method of Figure 9 and 10 any of the criticality levels (e.g., 401-415) in

[0143] In Figure 11 the criticality level (421) of the content of a memory region can be determined based on a content category (431), a priority (433) of an application (e.g., 212) that controls the content, and / or a priority requested by the application (e.g., 212) for the content.

[0144] Different content categories can have predetermined weights. When an application allocates a memory page for storing data, the application can identify a content category (431) of the memory page, such as application state, history / log data, media, sensor data, etc. The operating system (213) can assign predetermined weights (431) to criticality based on the content category.

[0145] Different applications can have predetermined weights to their criticality. A user of a user device can value the experience of one application (212) more than the experience of another application, and thus customize the weight assignments to different applications. In some cases, different applications can have interdependencies. Thus, an application that provides important services to other applications can be assigned a higher priority (433).

[0146] Different subsets of data of the same application and the same content category (431) can have different priorities (435). When an application (212) is programmed to request a customized priority (435), the application (212) can make improved predictions (e.g., 439) based on information that can not be available to the operating system (213). When an application (212) does not request a customized priority (435), the operating system (213) can track memory usage of the application (212) and request a priority (435) based on usage for the content.

[0147] The predetermined function can be used to combine the content category (431), the application priority (433),..., and / or the requested priority (435) to generate the criticality level (421). For example, a weight can be calculated for the content category (431), the application priority (433),..., the requested priority (435) and summed to obtain a total weight (421) as the criticality level. For example, the priorities (433, 435) can be summed to generate a weight that is applied to increase or decrease the weight of the content category (431) via multiplication.

[0148] Figure 12 A method of throttling network communications for memory-as-a-service is shown in accordance with one embodiment. For example, Figure 12 The method of Figure 2 , 6 or 9 can be implemented in the borrower device (201) as described in Figure 12 The method of Figure 1 device A (101), device B (103), or server P (105).

[0149] At block 451, a communication connection (e.g., 205) is established between the borrower device (201) and the lender device (203). For example, the connection (205) can be via the network and / or the Internet (109) as described in Figure 1 .

[0150] At block 453, the borrower device (201) communicates with the lender device (203) to obtain permission for the borrower device (201) to use an amount of memory (202) borrowed by the lender device (203) for access by the borrower device (201) via the communication connection (205).

[0151] At block 455, the operating system of the borrower device (201) allocates virtual memory to an application (e.g., 212) running in the borrower device (201).

[0152] At block 457, the operating system of the borrower device (201) configures the virtual memory to be at least partially hosted on the amount of memory (202) borrowed by the lender device (203) to the borrower device (201).

[0153] At block 459, the borrower device (201) determines a criticality level (e.g., 401-415) of content in a memory region (e.g., 291-299, 261-265, 273-275, and 281-283) used by the application (e.g., 212).

[0154] At block 461, the borrower device (201) allocates network bandwidth of the communication connection (212) to data communications used by memory regions in accessing the amount of memory (202) borrowed by the lender device (203) to the borrower device (201) via the communication connection (205) based on the criticality level.

[0155] The memory borrowed by the lender device (203) can be partially borrowed by the lender device (203) from another device (e.g., 245).

[0156] The criticality level (e.g., 401-415, 421) can be identified based at least in part on a category (431) of the content, a priority (433) of an application (e.g., 212) that controls the content, or a priority (435) requested by the application (e.g., 212) for the content, or any combination thereof.

[0157] For example, the application (e.g., 212) can request a priority (435) for content stored in a memory region based on a usage history of the content, a predicted usage (e.g., 439) of the content in a subsequent time period, or a frequency of usage (e.g., 437) of the content, or any combination thereof. In some cases, the operating system (213) can collect the usage history, determine the predicted usage (e.g., 439) and / or the frequency of usage (e.g., 437), and / or compute the requested priority (435) on behalf of the application (e.g., 212).

[0158] To allocate the network bandwidth, the operating system (213) of the borrower device (201) or the communication device (217) of the borrower device (201) can throttle / control the amount of data communications used by a memory region via the communication connection in a time period according to a ratio corresponding to the criticality level of the content in the memory region in accessing the amount of memory (202) borrowed by the lender device (203) to the borrower device (201). Thus, during the time period, the communications for the memory region can be considered as allowed according to the ratio; and the average speed of data communications for different memory regions can be controlled to be proportional to the ratio.

[0159] In some cases, the borrower device (201) can predict a decrease in the network bandwidth of the communication connection in a subsequent time period. In response, the operating system (213) can adjust the hosting of the virtual memory between the local memory (211) of the borrower device and the amount of memory (203) borrowed by the lender device (203) to the borrower device (201) according to the criticality level of the content in the memory region.

[0160] For example, the operating system (213) of the borrower device (201) can identify a first memory region having a criticality level lower than a second memory region. The operating system (213) can reconfigure the hosting of virtual memory such that a virtual memory region associated with the first memory region is migrated from being hosted or cached in local memory (211) to being hosted in the amount of memory (202) borrowed by the lender device (203) to the borrower device (201); and a virtual memory region associated with the second memory region can be migrated from being hosted in the amount of memory (202) borrowed by the lender device (203) to the borrower device (201) to being hosted or cached in local memory (211) of the borrower device (201).

[0161] In some embodiments, a memory management unit (MMU) of a computing device is configured to accelerate access to borrowed memory via a network connection.

[0162] For example, the memory management unit (MMU) (216) of the borrower device (201) can be configured to access not only local random access memory (211) of the borrower device (201) via a memory bus, but also to access borrowed memory (204) hosted in borrowed memory (202) of the lender device (203) via a network connection (205) using a communication device (217). The memory management unit (MMU) (216) can access borrowed memory (202) in the lender device (203) using the communication device (217) according to physical addresses (257) translated from virtual addresses (255) by the memory management unit (MMU) (216) without requiring the processor (215) of the borrower device (201) to execute instructions of its operating system (213).

[0163] For example, some routine operations performed by the operating system (213) when accessing borrowed memory (202) can be implemented in the memory management unit (MMU) (216) so that the routine operations can be performed without the processor (215) executing instructions in its execution unit. This MMU implementation / support can improve the efficiency of the processor (215) when accessing borrowed memory (204) that is physically located in borrowed memory (202) of the lender device (203).

[0164] In general, the operating system (213) can be programmed to handle more situations than the memory management unit (MMU) (216) can handle. For example, when a communication accessing borrowed memory (202) via a network connection (205) encounters an exceptional situation beyond the processing capabilities of the memory management unit (MMU) (216), the operating system (213) can be executed to handle such situations.

[0165] Figures 13 to 15 The technology of FIG. 1 can be implemented in a system of FIG. 6 or 7. Figures 13 to 15 The technology of FIG. 1 can be implemented in a system of FIG. 6 or 7. Figure 2 The memory service technology of FIG. 2 and Figure 3 The memory mapping technology of FIG. 3 can be implemented in a system of FIG. 6 or 7. Figure 1

[0166] In FIG. 2, the memory management unit (MMU) (216) of the borrower device (201) is configured to have a connection to the local random access memory (211) and a connection to the communication device (217) of the borrower device (201). In some cases, the communication device (217) is part of the memory management unit (MMU) (216). Figure 13 The virtual-to-physical memory mapping (253) cached in the translation lookaside buffer (TLB) (251) contains information to convert a virtual address (256) to a physical address (257).

[0167] When an instruction is executed in an execution unit (215) in the borrower device (201), a virtual address (255) stored in one of the registers (501) and / or generated by the execution unit can be used to load the instruction, retrieve an operand, and / or store a computation result. In this case, the borrower device (201) accesses a virtual memory identified by the virtual address (255).

[0168] When the virtual memory identified by the virtual address (255) is hosted in a memory page (259) in the local memory (211), the physical address (257) is configured to be sufficient for the memory management unit (216) to address the memory page (259) for a memory operation (e.g., a read or a write).

[0169] When the virtual memory identified by the virtual address (255) is hosted in a memory page (260) in the lent memory (202) that is physically inside the lender device (203), the physical address (257) is configured to contain sufficient information for the communication device (217) to transmit an access request to the lender device (203) via the computer network connection (205).

[0170]

[0171] ​​For example, when the virtual memory identified by the virtual address (255) is hosted in a memory page (260) in the borrowed memory (202), the physical address (257) can include a network address of the lending device (203) and a virtual memory address in a virtual memory space served by an operating system of the lending device (203). The memory management unit (MMU) (216) requests the communication device (217) to transmit an access request to the lending device (203) using the network address; and the access request includes the virtual address identifying the memory page (260) in the lending device (203).

[0172] When the communication device (237) receives the access request, the communication device (237) can be configured to instruct the memory management unit (MMU) (236) to access the memory page (260) identified by the virtual address included in the access request from the borrowing device (201) in a manner similar to how the processor (235) instructs the memory management unit (MMU) (236) to access the virtual address. In some cases, the communication device (237) is part of the memory management unit (MMU) (236).

[0173] For example, when the virtual address is converted to a physical address of the memory page (260) using the virtual-to-physical memory mapping of the lending device (203), the memory management unit (MMU) (236) performs the address conversion and uses the physical memory address to access the memory page (260). When the virtual-to-physical memory mapping used to convert the virtual address is not already in the memory management unit (MMU) (236) of the lending device (203), the operating system (233) of the lending device (203) can be executed to load the relevant portion of the virtual-to-physical memory mapping into the memory management unit (MMU) (236) of the lending device (203) so that the memory management unit (MMU) (236) can perform the address conversion to access the memory page (260).

[0174] In some cases, the lending device (203) can host virtual addresses used by the borrowing device (201) in the storage device (232). In response to a miss / page fault in the memory management unit (MMU) (236) to convert the virtual address, the memory management unit (MMU) (236) causes the processor (235) to execute the operating system (233) that loads the data content from the storage device (232) into the borrowed memory (202), updates the translation lookaside buffer (TLB) of the memory management unit (MMU) (236) to facilitate access. Alternatively, the operating system (233) can service the access request directly from the storage device without caching or buffering or rehosting it in the local memory (231) of the lending device (203).

[0175] In some cases, the lender device (203) can host the virtual addresses used by the borrower device (201) in another lender device (e.g., 205). In this case, the lender device (203) can access its lender (e.g., 205) in a similar manner as the borrower device (201) accesses the lender device (203).

[0176] Optionally, when a virtual address (255) accessed in one of the execution units (215) of the borrower device (201) is translated to a physical address (257) accessed via the communication device (217), the communication device (217) can migrate the virtual address region from the lender device (203) into a buffer (505) of the communication device (217), as explained in Figure 14

[0177] For example, when a virtual address (256) in a virtual memory page is accessed, the communication device (217) can migrate the entire page (or a portion thereof) into a buffer (505) of the communication device (217) to anticipate further accesses to the page.

[0178] Alternatively, the memory management unit (MMU) (216) of the borrower device (201) can be configured to reserve a portion of the local random access memory (211) as a buffer for caching a portion of the lent memory (203), as explained in Figure 15

[0179] Optionally, the memory management unit (MMU) (216) of the borrower device (201) can be further configured to manage adjustments of the hosting of the virtual memory region identified in the virtual physical memory page (253) in a similar manner as explained in Figure 5

[0180] ​​​For example, when the memory management unit (MMU) (216) determines that virtual regions hosted in the borrowed memory (202) of the lender device (203) are accessed more frequently and / or recently than virtual regions hosted in the local memory (211), the memory management unit (MMU) (216) can use the communication device (217) to migrate the more frequently and / or recently accessed virtual regions to be hosted in the local memory (211) and evict the less frequently and / or recently accessed virtual regions to be hosted in the borrowed memory (202). Thus, the memory management unit (MMU) (216) can optimize the hosting of virtual memory regions identified in the virtual to physical memory mapping (253) cached in the translation lookaside buffer (TLB) (251) and update the virtual to physical memory mapping (253) cached in the translation lookaside buffer (TLB) (251) according to the adjustment. The operating system (213) of the borrower device (201) can be used to further adjust the hosting of other virtual memory regions.

[0181] Figure 16 and 17 It is explained a hardware accelerated configuration to provide access to borrowed memory according to some embodiments. For example, Figure 13 , 14 The configuration of the lender device (203) explained in Figure 16 or 17 can be replaced with the configuration of

[0182] In Figure 16 , the lender device (203) has a peripheral bus (511) and a memory bus (513).

[0183] The communication device (237) and the storage device (232) of the lender device (203) are connected to the processor (235) of the lender device (203) via the peripheral bus (511). The local random access memory (231) of the lender device (203) is connected to the processor via the memory bus (513).

[0184] The operating system (233) can be initially stored in the storage device (232) and subsequently loaded into the random access memory (231) for execution.

[0185] When the communication device (237) receives a memory access request (507) identifying a virtual memory address (509) allocated by the operating system (233) for a borrowed memory (204) used by the borrower device (201), the communication device (237) is configured to request the processor (235) to process according to the memory access request (509).

[0186] Upon receiving the access request (507) at the communication device (237), the operating system (233) running in the lender device (203) can host the virtual address (509) in the storage device (232) or in the random access memory (231) (e.g., via configuration of the memory map (227)).

[0187] If the virtual address (509) is hosted in the memory (231) and the memory management unit (MMU) (236) has a cache portion of the memory map (227) to translate the virtual address (509), the processor (235) can handle the access request (507) by accessing the physical address of the memory page (260) determined from the cache portion of the memory map (227).

[0188] If the virtual address (509) is hosted in the memory (231) and the memory management unit (MMU) (236) does not have a cache portion of the memory map (227) to translate the virtual address (509), the processor (235) can execute the operating system (233) to update the cache portion of the memory map (227) so that the memory management unit (MMU) (236) can translate the virtual address (509) to the physical address of the memory page (260).

[0189] If the virtual address (509) is hosted in the storage device (232), such as a hard disk drive or solid state drive, the memory management unit (MMU) (236) does not have a cache portion of the memory map (227) to translate the virtual address (509) (e.g., by generating a page fault). In response, the memory management unit (MMU) (236) causes the processor (235) to execute the operating system (233), which can be configured to implement the access request (507) by accessing the storage device (232) and / or migrate the virtual memory region (e.g., virtual memory page) to the random access memory (231).

[0190] If the virtual address (509) is hosted in another lender device (e.g., 245), the lender device (203) translates the virtual address (509) to a physical address that identifies a network address of its lender device (e.g., 245) and a virtual address assigned by its lender device (e.g., 245) that can optionally be configured to be the same as the virtual address (509) in the uniform address space. The lender device (203) can then access its lender device (e.g., 245) in a manner similar to how the borrower device (201) accesses the lender device (203).

[0191] The access request (507) can correspond to a form configuration of a memory access requested during instruction execution in the processor (215) of the borrower device (201). For example, when the processor (215) of the borrower device (201) requests to load an instruction from a virtual address (255), the access request (507) is configured to request retrieval of the instruction from a virtual address (509), which can optionally be configured to be the same as the virtual address (255) in the unified address space.

[0192] For example, when the processor (215) of the borrower device (201) requests to load an operand from a virtual address (255), the access request (507) is configured to request retrieval of the operand from a virtual address (509); and when the processor (215) of the borrower device (201) requests to store a computation result at the virtual address (255), the access request (507) is configured to request retrieval of the operand from a virtual address (509).

[0193] Optionally, the access request (507) can be configured to implement migration of a virtual address region. For example, when accessing the virtual address (509), the communication device (237) is configured to automatically facilitate migration of the virtual memory region between the lender device (203) and the borrower device (201).

[0194] Optionally, the communication device (237) is implemented as part of a memory management unit (MMU) (236) of the lender device (203).

[0195] Optionally, the memory management unit (MMU) (236) is configured to include a network controller (523) to operate the communication device (237), as described in Figure 17

[0196] In Figure 17 , the memory management unit (MMU) (236) has a memory controller (521) configured to access a memory page (260) using a physical address of the memory (231). In addition, the memory management unit (MMU) (236) has a network controller (521) configured to handle network-based memory access requests (e.g., 507). Such network-based memory access requests (507) can be requests from its borrower device (e.g., 201) or its lender device (e.g., 245).

[0197] Figure 18 A method to accelerate access to borrowed memory via a memory management unit is shown, according to one embodiment. For example, Figure 18 the method of Figure 1 may be implemented in the device A (101) or the device B (103) or the server P (105) described inFor example,The method of Figure 18 may be implemented in a borrower device (201) as described in Figure 2 , 6 9, 13, 14, or 15. For example, Figure 18 The method of Figure 2 , 3 or 13-17 can be implemented in a memory management unit (216) or memory management unit (236) as described.

[0198] At block 531 in Figure 18 , the memory management unit (e.g., 216 or 236) caches a virtual-to-physical memory mapping (e.g., 253) in a translation lookaside buffer (e.g., 253) of the memory management unit (e.g., 216 or 236).

[0199] For example, the virtual-to-physical memory mapping (e.g., 253) can be part of a page table managed by an operating system (e.g., 213 or 233) of a computing device (e.g., 201 or 203) in which the memory management unit (e.g., 216 or 236) is configured.

[0200] At block 533, the memory management unit (e.g., 216 or 236) receives a request to access a virtual memory address (e.g., 255 or 509) for execution of an instruction in a microprocessor (e.g., 215 or 235).

[0201] For example, the virtual memory address (255) can be stored in a register (501) for execution of an instruction in the processor (215). The virtual memory address (255) can be used to load an instruction from the virtual memory address (255), load an operand of an instruction from the virtual memory address (255), or store a result of a computation generated by an execution unit (503) after execution of the instruction.

[0202] In some cases, the virtual memory address (509) is received in a communication device (237) in a memory access request from a network connection to the borrower device (e.g., 201); and the communication device (237) is configured to request the memory management unit (236) to process the access request (507).

[0203] At block 535, the memory management unit (e.g., 216 or 236) uses the virtual-to-physical memory mapping (e.g., 253) cached in the translation lookaside buffer (e.g., 253) to convert the virtual memory address (e.g., 255) to a physical memory address (e.g., 257).

[0204] At block 537, it is determined whether the physical memory address (e.g., 257) is for local memory (e.g., 211 or 231).

[0205] For example, a memory management unit (e.g., 216 or 236) can have a connection to both a memory bus (e.g., 511) via a memory controller (e.g., 521) and to a computer network (e.g., 109) via a network controller (523).

[0206] At block 539, if the physical memory address (e.g., 257) is determined (537) to be for local memory (e.g., 211 or 231) (e.g., a first memory type), the memory management unit (e.g., 216 or 236) instructs a memory controller (521) connected to the memory bus (513) to access the memory page (259) at the physical address (257).

[0207] At block 541, if the physical memory address (e.g., 257) is determined (537) not to be for local memory (e.g., 211 or 231) (e.g., a second memory type), the memory management unit (e.g., 216 or 236) instructs a network controller (523) connected to the computer network connection (205) to access the memory page (260) according to the physical address (257).

[0208] A memory management unit (MMU) (216 or 236) configured to perform the method of Figure 18 The memory management unit (MMU) (216 or 236) configured to perform the method of

[0209] A communication device (e.g., 201 or 203) having such a memory management unit (MMU) (216 or 236) can have a memory bus coupled to local random access memory (e.g., 211 or 213) and at least one microprocessor (e.g., 215 or 235). The microprocessor (e.g., 215) can further have registers (e.g., 501) and an execution unit (e.g., 503).

[0210] A computing device (e.g., 201 or 203) has an operating system (e.g., 213 or 233) including instructions that, when executed by at least one microprocessor (e.g., 215 or 235), cause the computing device to borrow an amount of memory from a lender device (e.g., 203 or 245) using a communication device (e.g., 217 or 237) via a network connection (205).

[0211] The execution unit (503) is configured to execute instructions using at least virtual memory addresses mapped to the amount of memory borrowed from the lender device (e.g., 203 or 245).

[0212] For example, after retrieving the first virtual memory address (255) from the register (501) for executing an instruction in the execution unit (503), the memory management unit (MMU) (216) translates the first virtual memory address (255) to a first physical address (257) that identifies the lending device (e.g., 203 or 245) and a second virtual memory address (509) via the network connection (205). The memory management unit (MMU) (216) instructs the communication device (217) to access the memory (260) lent by the lending device (203) to the computing device (201) via the network connection (205) using the second virtual memory address.

[0213] For example, the first physical address (257) can include a computer network address of the lending device (203).

[0214] Execution of the instruction in the execution unit (503) can generate a memory operation to read or write at the first virtual memory address (255); and the memory management unit (253) is configured to generate a request (507) for the memory operation at the second virtual memory address (509) and instruct the communication device (217) to transmit the request (507) to the lending device (203) via the communication connection (205).

[0215] In operation, the second virtual memory address (509) can be equal to the first virtual memory address (255) such that the lending device (203) and the borrowing device (201) can use a unified virtual address space. For example, an operating system can be configured to receive an identification of an amount of borrowed memory (204) based on a virtual memory address specified by the lending device (203) in the unified virtual address space; and the operating system can be configured to allocate virtual memory directly from the virtual memory address in the unified virtual address space to an application program.

[0216] Optionally, the memory management unit (217) includes a buffer (505); and the memory management unit (216) is further configured to instruct the communication device (217) to communicate with the lending device (203) to establish a cache in the buffer (505) for a portion of an amount of memory (202) lent by the lending device (203) to the borrowing device (201) in response to receiving the first virtual memory address (255) from the register (501). For example, when a virtual address (255) in a page table is used, the communication device (217) can cache a memory page according to the page table.

[0217] Optionally, the memory management unit (217) is further configured to dynamically change the memory mapping between virtual memory and physical memory. For example, virtual memory identified by a set of virtual memory addresses can be initially mapped (e.g., in a translation lookaside buffer (TLB) (251)) to memory (202) loaned by the lender device (203) to the borrower device; and can be mapped changed to re-map the virtual memory to a portion of local random access memory (211).

[0218] For example, the memory management unit (217) can swap mappings of two virtual memory regions identified in a virtual-to-physical memory mapping (253) cached in a translation lookaside buffer (TLB) (251) such that a first virtual memory region that was initially mapped to a region in local memory (211) is re-mapped to a region in loaned memory (202) in the lender device (203), and a second virtual memory region that was initially mapped to a region (or another region) in loaned memory (202) in the lender device (203) is re-mapped to a region (or another region) in local memory (211).

[0219] For example, the memory management unit (217) can be further configured to identify the first virtual memory region and the second memory region for swapping based on a history of memory usage in a past time period or a predicted memory usage in a future time period. For example, least recently used and / or least frequently used virtual memory pages can be swapped from local memory (211) to loaned memory (202); and most recently used and / or most frequently used virtual memory pages can be swapped from loaned memory (202) to local memory (211).

[0220] In general, each of the devices or servers discussed above (e.g., 101, 103, 105, 107, 201, 203) can be implemented as one or more data processing systems.

[0221] A typical data processing system can include interconnects (e.g., buses and system core logic) that interconnect microprocessors and memory. The microprocessors can also have on-die cache hierarchies.

[0222] The interconnects interconnect the microprocessors and memory together and also interconnect them to input / output (I / O) devices via an I / O controller. The I / O devices can include display devices and / or peripheral devices such as mice, keyboards, modems, network interfaces, printers, scanners, video cameras, and other devices known in the art. In one embodiment, when the data processing system is a server system, some of the I / O devices (e.g., printers, scanners, mice, and / or keyboards) are optional.

[0223] The interconnect can include one or more buses that connect the various bridges, controllers and / or adapters to one another. In one embodiment, the I / O controller includes a USB adapter to control Universal Serial Bus (USB) peripheral devices, and / or an IEEE- 1394 bus adapter to control IEEE- 1394 peripheral devices.

[0224] The memory can include one or more of read-only memory (ROM), volatile Random Access Memory (RAM), and non-volatile memory such as a hard disk drive, flash memory, etc.

[0225] The volatile RAM typically implements dynamic RAM (DRAM) that requires power continually in order to refresh or maintain the data in memory. The non-volatile memory can be a magnetic hard drive, a magnetic optical drive, an optical drive, a DVD, a Blu-Ray, a flash memory, or other type of memory system which maintains data without power. The non-volatile memory can also be a random access memory.

[0226] The non-volatile memory can be a local device coupled directly to the rest of the components in the data processing system. A non-volatile memory in the system can also be used as removable memory, such as a memory card, that can be removed and connected to a different data processing system.

[0227] In this disclosure, some functions and operations are described as being performed by or caused to be performed by a software code to simplify description. However, such expressions are also used to specify that the functions might be implemented by execution of the code / instructions by a processor, such as a microprocessor or any IP block (system on chip) of a SoS.

[0228] Alternatively, or in combination, the functions and operations as described herein can be implemented using special-purpose circuitry having or not having associated software instructions, such as using an application-specific integrated circuit (ASIC) or a field-programmable gate array (FPGA). Embodiments can be implemented using hard-wired circuitry without software instructions, or in combination with software instructions. Thus, the techniques are not limited to any specific combination of hardware circuitry and software, nor to any specific source for the instructions executed by the data processing system.

[0229] While one embodiment can be implemented in fully functioning computers and computer systems, various embodiments can be distributed over a network and can be implemented in computing facilities that are not all physically proximate to one another, and can be applicable regardless of the specific type of machine or computers readable media actually used to implement the distributed.

[0230] At least some aspects disclosed can be embodied, at least in part, in software. That is, techniques can be effected in a computer system or other data processing system in response to its processor, such as a microprocessor, executing sequences of instructions contained in memory, such as ROM, volatile RAM, non-volatile memory, cache or a remote storage device.

[0231] Routines executed to implement the embodiments can be implemented as part of an operating system or a specific application, component, program, object, module or sequence of instructions referred to as "computer programs." The computer programs typically comprise one or more instructions set at various times in various memory and storage devices in a computer, and that, when read and executed by one or more processors in a computer, cause the computer to perform operations necessary to execute elements involving the various aspects.

[0232] Machine-readable media can be used to store software and data which when executed by a data processing system causes the system to perform various methods. The executable software and data can be stored in various places including for example ROM, volatile RAM, non-volatile memory and / or cache. Portions of this software and / or data can be stored in any one of these storage devices. Further, the software and data can be obtained on physical media that is distributed in some form, for example, on a file or disc media or through electronic transmission such as by a wireless transport or over the internet. Some embodiments of virtual components, methods, techniques and data can be downloaded as a part of software and / or applications supplied after the sale and distribution of the hardware platform on which the software and / or applications

[0233] Examples of computer-readable media include but are not limited to non-transitory, recordable and non-recordable type media such as volatile and non-volatile memory devices, read only memory (ROM), random access memory (RAM), flash memory devices, floppy and other removable disks, disk storage, optical storage (e.g., Compact Disk Read Only Memory (CD ROM), digital versatile disk (DVD), etc.), among others. The computer-readable media can store instructions.

[0234] The instructions can also be embodied in digital and analog communication links, for example, carrier waves, infrared signals, digital signals, etc. The propagated signals, such as carrier waves, infrared signals, digital signals, etc. are not tangible, physical entities, but are rather a change in state of the entity. However, the changes in state of the entity, such as in its physical structure, are that which can be reflected in a tangible medium for technical use, particularly for example, in the formulations of waves, particles, or other physical entities in the communication media.

[0235] In general, a machine readable medium includes any mechanism that provides (i.e., stores and / or transmits) information in a form accessible by a machine (e.g., a computer, network device, personal digital assistant, manufacturing tool, any device with a set of one or more processors, etc.).

[0236] In various embodiments, hardwired circuitry can be used in combination with software instructions to implement the techniques. Thus, the techniques are not limited to any specific combination of hardware circuitry and software. Nor are the techniques limited to any particular source of the instructions for execution by data processing system.

[0237] The above description and drawings are illustrative, and are not to be construed as limiting. Numerous specific details are described to provide a thorough understanding. However, in certain instances, well known or conventional details are not described in order to avoid obscuring the description. References to one or an embodiment in the present disclosure are not necessarily references to the same embodiment; and, such references mean at least one.

[0238] In the foregoing specification, the disclosure has been described with reference to specific exemplary embodiments thereof. It will be evident that various modifications can be made thereto without departing from the broader spirit and scope of the disclosure as set forth in the following claims. The Specification and drawings are, accordingly, to be regarded in an illustrative rather than a restrictive sense.

Claims

1. A computing device comprising: communication devices; Random access memory; as well as At least one microprocessor having a memory management unit, registers, and an execution unit, the memory management unit being coupled to the random access memory and the communication device; The computing device is configured to access a amount of memory at a remote device via a network connection through the communication device; The execution unit is configured to execute instructions using at least virtual memory addresses mapped to the amount of memory at the remote device; and The memory management unit is configured to: Retrieve the first virtual memory address from the register for executing instructions in the execution unit; The first virtual memory address is translated into a first physical address, and the first physical address identifies the remote device and the second virtual memory address via the network connection; A memory access request for identifying a memory page is generated via the network connection; as well as The communication device is instructed to use the second virtual memory address to access the memory at the remote device via the network connection.

2. The computing device of claim 1, wherein the first physical address includes the computer network address of the remote device.

3. The computing device of claim 2, wherein executing the instruction in the execution unit causes a memory operation to be read from or written to the virtual memory address; and the memory management unit is configured to generate a request for the memory operation at the second virtual memory address and instruct the communication device to transmit the request to the remote device via the communication connection.

4. The computing device according to claim 3, wherein the second virtual memory address is equal to the first virtual memory address.

5. The computing device of claim 3, wherein the computing device is configured to receive an identifier of the amount of memory based on a virtual memory address specified by the remote device; and to allocate the second virtual memory address from the virtual memory address specified by the remote device.

6. The computing device of claim 1, wherein the memory management unit includes a buffer; and the memory management unit is further configured to instruct the communication device to communicate with the remote device in response to the first virtual memory address received from the register to establish a cache in the buffer for a portion of the memory amount at the remote device.

7. The computing device of claim 1, wherein the memory management unit is further configured to change from mapping the set of virtual memory addresses to the memory amount at the remote device to mapping the set of virtual memory addresses to the random access memory.

8. A microprocessor comprising: register; Execution unit; as well as The memory management unit has: A translation backup buffer is configured to store a virtual-to-physical memory mapping. A memory controller configured to access random access memory via a memory bus; as well as A network controller configured to control communication devices connected to a wired or wireless network; The registers are configured to store virtual memory addresses for executing instructions in the execution unit; The memory management unit is configured to translate the virtual memory address into a physical memory address according to the virtual-to-physical memory mapping in the translation backup buffer; The memory controller is configured to access a first memory page in the random access memory using the physical memory address when the physical memory address is of the first type; The network controller is configured to access a second memory page via a network connection through the communication device when the physical memory address is of the second type; and The memory management unit is configured to generate a memory access request identifying the second memory page via the network connection.

9. The microprocessor of claim 8, wherein the physical memory address of the second type identifies the computer network address of the computing device.

10. The microprocessor of claim 9, wherein executing the instruction in the execution unit comprises loading the instruction from the virtual memory address, loading the operand of the instruction from the virtual memory address, or storing the computation result of the instruction into the virtual memory address.

11. The microprocessor of claim 10, wherein the memory access request is generated based on the physical memory address of the second type, and the memory management unit is configured to instruct the network controller to transmit the memory access request via the network connection.

12. The microprocessor of claim 11, wherein the memory access request is configured to identify a second memory page using the virtual memory address.

13. The microprocessor of claim 9, wherein the memory management unit includes a buffer; and the memory management unit is further configured to instruct the network controller to communicate with the computing device via the network connection to cache a memory region containing the second memory page in the buffer.

14. The microprocessor of claim 9, wherein the memory management unit is further configured to instruct the memory controller and the network controller to perform an exchange of first content in a first memory region having the first memory page with second content in a second memory region having the second memory page, and to update the virtual-to-physical memory mapping based on the exchange.

15. A memory management unit, comprising: The backup buffer is converted and configured to cache virtual-to-physical memory mapping; A memory controller configured to access random access memory connected to the memory controller via a memory bus; as well as A communication device configured to communicate with a computing device via a wired or wireless network using a network connection; The memory management unit is configured to translate virtual memory addresses into physical memory addresses based on the virtual-to-physical memory mapping in the translation backup buffer. The memory controller is configured to access a first memory page in the random access memory using the physical memory address when the physical memory address is used for the random access memory; The communication device is configured to access a second memory page via the network connection when the physical memory address is used for the memory of the computing device; and The memory management unit is further configured to: From mapping the first virtual memory region to a physical memory region that can be accessed via the memory controller, Instead, the first virtual memory region is mapped to a physical memory region that can be accessed via the communication device.

16. The memory management unit of claim 15, wherein the communication device is configured to load an instruction from the second memory page according to the virtual memory address, load an operand of the instruction from the second memory page, or store a calculation result of the instruction in the second memory page.

17. The memory management unit of claim 16, wherein the memory management unit is configured to generate a memory access request based on the physical memory address of the memory for the computing device; and the memory access request is configured to identify the second memory page using a memory address in a unified address space, and to request the computing device to provide the instruction from the second memory page, provide the operand of the instruction from the second memory page, or store the computation result of the instruction in the second memory page.

18. The memory management unit of claim 17, wherein the memory address in the unified address space is the same as the virtual memory address.

19. The memory management unit of claim 15, wherein the memory management unit is further configured to: Mapping the second virtual memory region to a physical memory region that can be accessed via the communication device. Instead, the second virtual memory region is mapped to the physical memory region that can be accessed via the memory controller.

20. The memory management unit of claim 19, wherein the memory management unit is further configured to identify the first virtual memory region and the second virtual memory region based on memory usage history in a past time period or predicted memory usage in a subsequent time period.

21. The memory management unit of claim 15, wherein the communication device is configured to communicate with the computing device at least via a fifth-generation cellular network.

Images