Enhanced page information coprocessor

Abstract

A processing system includes a host processor and a co-processor. The host processor can be coupled to a memory subsystem having at least one memory and operates to execute system software that employs memory address translations based on one or more page tables stored in the memory subsystem. The co-processor likewise can be coupled to the memory subsystem and operates to perform iterations of a page table walk through one or more page tables maintained for the memory subsystem and to perform one or more page management operations on behalf of the system software based on the iterations of the page table walk. The page management operations performed by the co-processor include analysis data aggregation, free list management, and page allocation, page migration management, page table error detection, etc.

Description

Background Technology

[0001] Many processing systems employ a paging memory allocation scheme, in which data moves between secondary storage devices (e.g., mass storage devices) and memory in blocks typically of fixed size (called “pages”). Each page represents a corresponding subset of memory address locations. A set of one or more page tables facilitates the translation of the virtual memory address of a referenced memory location into the physical memory address of that memory location. Typically, these page tables are stored in memory, except for a translation back buffer (TLB) that acts as a cache that stores copies of a small subset of page table entries. Therefore, unless address translation involves one of the several page table entries present in the TLB, the address translation process involves accessing page table entries in the page tables in memory, and thus involves one or more memory access operations. Consequently, the operating system or hypervisor consumes a significant portion of the processing bandwidth of the central processing unit (CPU) or other main processor in traversing and otherwise managing the page tables in memory. The load on the page management process on the main processor system continues to increase because, despite the growth in memory size, the page size tends to remain fixed (e.g., at 4 kilobytes) due to legacy compatibility and other reasons, thus causing the main processor to manage increasingly larger page tables. Attached Figure Description

[0002] This disclosure will be better understood by referring to the accompanying drawings, and the numerous features and advantages of this disclosure will become apparent to those skilled in the art. The same reference numerals are used in different drawings to indicate similar or identical items.

[0003] Figure 1 This is a block diagram illustrating a processing system employing a coprocessor for memory page management according to some implementation schemes.

[0004] Figure 2 This shows in more detail the implementation details based on some of the schemes. Figure 1 A block diagram of the coprocessor.

[0005] Figure 3 This is a block diagram illustrating page tables and corresponding page table entries (PTEs) according to some implementation schemes.

[0006] Figure 4 This illustrates the implementation scheme by... Figure 1 and Figure 2 The flowchart shows the method for page table evaluation and management provided by the coprocessor.

[0007] Figure 5 This illustrates the implementation scheme by... Figure 1 and Figure 2 The flowchart shows the page migration method provided by the coprocessor. Detailed Implementation

[0008] In conventional processing systems, system software (i.e., one or both of the operating system (OS) or hypervisor (HV)) periodically traverses the page table, reading and selectively clearing access (A) bits, dirty (D) bits, and other status bits. By sampling pages during page table traversal, the system software can gather a limited amount of usage information, which is provided to the memory manager to determine which pages to evict in order to accept incoming pages to satisfy memory demands. However, although system memory size has increased, page size has remained relatively fixed (e.g., 4 kilobytes per page) for various reasons. Consequently, page table size has increased, and therefore the proportion of processor cycles spent by system software collecting page statistics has increased, which reduces the system's ability to perform user tasks and other high-priority tasks.

[0009] To reduce the memory management burden on the main processor, such as the central processing unit (CPU), graphics processing unit (GPU), or other execution system software, in at least one embodiment, the processing system employs a separate dedicated enhanced page information coprocessor (EPIC). This EPIC operates to offload some or all of the page management responsibilities conventionally undertaken by the system software, and in some embodiments, provides additional enhanced page management features. This coprocessor (referred to herein as a “memory processing unit” or “MPU”), which has limited general processing power compared to the main processor, is configured by the system software to perform iterations of page table traversal of one or more page tables, aggregating or otherwise generating various information in the process without utilizing the resources of the main processor. The information generated during page traversal iterations includes, for example, information about which pages have been accessed, which pages have been modified (i.e., “dirty”), access frequency, page table entries, or the integrity of the page tables themselves. The MPU uses this information to generate one or more ordered lists, such as an accessed page list or a dirty page list. In some embodiments, these ordered lists are provided to the system software, which uses them to select pages to be evicted. In other embodiments, the MPU performs page selection and eviction independently of the main processor, based on this information and according to a policy specified by the system software. Additionally, in some embodiments, the processing system employs a Non-Uniform Memory Access (NUMA) architecture with multiple memories, and the MPU operates to identify candidate pages for migration between memories. In some embodiments, these candidate pages are informed to the system software for page migration controlled by the system software. In other embodiments, page migration is performed independently of the system software. By offloading various page management operations and reducing the burden on the system software, the MPU allows the main processor to spend a larger proportion of its cycle time performing other tasks.

[0010] Figure 1 A processing system 100 is illustrated, according to some embodiments, employing an Enhanced Page Information Coprocessor (EPIC) to offload memory page management from the main processor and provide supplementary memory page management operations. The processing system 100 is used in any of a variety of electronic devices, including desktop computers, laptop computers, tablet computers, servers, computing-enabled cellular phones (“smartphones”), game consoles, computing-enabled televisions, etc. The processing system 100 includes one or more main processors 102, a memory subsystem 104 consisting of one or more memories 106 (e.g., memories 106-1 and 106-2), and an EPIC in the form of a memory processing unit (MPU) 108. The main processor 102, memories 106, and MPU 108 are connected for use via one or more buses, networks, or other interconnects (for illustration purposes, these have been removed from...). Figure 1 (The text is omitted here) to convey signaling and data.

[0011] The main processor 102 operates to execute one or more system software applications having executable instructions stored in at least one memory 106 to manage the entire system 100 and facilitate the execution of user software applications. These system software applications include, for example, one or both of an operating system (OS) or a hypervisor (HV), which are mentioned in combination or as alternatives to OS / HV 110. Examples of the main processor 102 include a central processing unit (CPU), a graphics processing unit (GPU), an artificial intelligence (AI) processor, an application-specific integrated circuit (ASIC), etc. For illustrative purposes, the main processor 102 is described as a CPU in the example implementations below, and more specifically as a CPU implementing the x86 instruction set architecture (ISA), but unless otherwise stated, the corresponding description applies equally to other processor types and other ISAs.

[0012] The main processor 102 includes one or more processor cores 112, such as processor cores 112-1 and 112-2, which operate to execute OS / HV 110 and user software applications implemented at system 100. The main processor 102 also includes one or more interfaces to the memory subsystem 104, such as one or more of a memory management unit (MMU) 114, an input / output MMU (IOMMU) 116, and a direct memory access (DMA) engine 118. As known in the art, the MMU 114 typically operates to transfer data between the processor core 112 (and one or more caches of the associated cache hierarchy (not shown)) and one or more memories 106; the IOMMU 116 typically operates to transfer data between the cache hierarchy, one or more memories 106, and one or more peripheral devices (not shown); and the DMA engine 118 operates to move data into and out of one or more memories 106 without involving the processor core 112 or the MMU 114.

[0013] In at least one embodiment, each memory 106 of memory subsystem 104 is implemented as a “paged” memory, such that a set of physical storage locations (or subsets thereof) of memory 106 are logically divided into pages 120 of page set 122. Typically, each page 120 of a given memory 106 has the same fixed size as all other pages of the same memory 106, where the page size is typically set by a strategy defined by OS / HV 110. For example, physical storage locations of memory in an x86-based system may be organized into 4KB pages 120 for various reasons, including backward compatibility, but different page sizes may be mixed in certain cases. Each page 120 is managed as a whole block relative to the main processor 102 accessing memory 106. Therefore, when a page management operation is performed to transfer identified data from memory 106 to secondary storage components (e.g., disk drives) of computer system 100, the entire page 120 containing that data is typically transferred to memory subsystem 104 as part of the page operation. Similarly, when a page-out operation is performed to transfer identified data from memory 106 to secondary storage, the entire page 120 containing the specified data is transferred. Although the page size may vary, each page is transferred as a unit.

[0014] Since the addressable memory space of processing system 100 is typically much larger than the size of one or more memories 106, only a subset of the available pages of data can be stored in memory 106 at any given time. Therefore, in at least one embodiment, OS / HV 110 employs a virtual memory management scheme with a virtual memory space using a set of virtual addresses (often also referred to as “linear addresses”) that is larger than a set of physical addresses for the storage locations of one or more memories 106. With this scheme, OS / HV 110 employs a virtual-to-physical address translation process to translate each virtual address into a corresponding physical address, which is then used to access the corresponding page 120 in memory 106 (assuming the referenced page 120 is actually already loaded into memory 106). To facilitate this virtual-to-physical address translation, processing system 100 employs a page table structure 124 consisting of one or more page tables 126. In at least one implementation, the page table structure 124 is a hierarchical page table structure, such that one subfield of the virtual address identifies an entry in the first page table that points to the second page table, another subfield of the virtual address identifies an entry in the second page table that points to the third page table, and so on.

[0015] To illustrate, a typical long-mode nested paging scheme for 4KB pages and 64-bit virtual addresses employs four levels of page tables. At the first level is a Page-Mapping Level 4 (PML4) table containing multiple entries, each pointing to a specific PDP table within multiple Page Directory Pointers (PDP) tables. A nine-bit PML4 offset field of the virtual address specifies which entry in the PML4 table is used. Each entry in each PDP table points to a specific PD table within multiple Page Directory (PD) tables, and a nine-bit PDP offset subfield of the virtual address specifies the specific entry to be used in the specified PDP table. Each entry in each PD table points to a specified last-level page table among multiple last-level page tables, and a nine-bit PD offset field of the virtual address specifies the specific entry to be used in the specified PD table. Each last-level page table includes a set of Page Table Entries (PTEs), where each PTE stores a 52-bit physical address portion, which is combined with bits from a 12-bit physical page offset subfield of the virtual address to generate a physical address mapped to the virtual address.

[0016] It will be understood that the processing system 100 typically supports multiple processes simultaneously via context switching or another time-division multiplexing method, and some or all of these processes typically have their own corresponding virtual address spaces. Therefore, each process or context typically employs its own separate page table structure 124. In the example long-mode hierarchical paging scheme described above, the base address of the top table (PML4 table) is specified using a specific control register 128, which stores the identifier of the currently running process / context and is used to specify the base address. For illustration, in an x86 context, this control register 128 is implemented by the CR3 register, which stores the Process Context Identifier (PCID) that identifies the current process / context and is used to calculate the base address of the PML4 table of the page table structure 124 for that identified process / context. For ease of illustration, the operation of the processing system 100 will be described below with reference to the above long-mode paging scheme, and referenced below... Figure 3 This document describes an example format for PTE. However, it will be understood that the techniques described herein are not limited to this example implementation, but are applicable to any of the various paging schemes using the guidance provided herein.

[0017] Since page table 126 is stored in one or more memories 106, performing each virtual-to-physical address translation would otherwise involve lengthy memory access operations. Therefore, to facilitate fast address translation, in at least one embodiment, the main processor 102 utilizes a Translation Lookahead Buffer (TLB) 130, a cache structure that operates to locally store copies of a subset of recently used PTEs for access by the MMU 114. Thus, each time a page 120 is allocated in memory 106, the PTEs from page table 126 for that page 120 are also stored in TLB 130 until TLB 130 is full. Thereafter, one or more TLB management schemes are employed to determine which PTEs will have copies stored in TLB 130 and which PTEs should have their copies evicted from TLB 130 to make room for newly arriving TLB entries. Such schemes are typically based on access recentity, access frequency, etc. Conventionally, MMU 114 manages TLB 130. However, as described below, in some implementations, the MPU 108 operates to perform some or all of the management functions of the TLB 130 instead of the MMU 114.

[0018] MPU 108 is implemented as a coprocessor for one or more main processors 102 for one or both of the following purposes: offloading routine page management operations performed by the OS / HV 110 in a conventional system and thus consuming a portion of the execution bandwidth of processor core 112; and providing enhanced page management operations that utilize the MPU 108's ability to dedicate most or all of its execution bandwidth to page management operations. That is, apart from page management, in at least one embodiment, MPU 108 has limited general processing capabilities compared to main processor 102 (i.e., it cannot perform the general duties of main processor 102). Therefore, in some embodiments, MPU 108 is implemented as a software or firmware instruction execution processor, such as a Reduced Instruction Set Computer (RISC) processor, wherein software / firmware instructions that manipulate MPU 108 to perform the functions described herein are stored in memory 106, a Basic Input / Output System (BIOS), or other read-only memory (ROM), etc. In other embodiments, the MPU 108 is implemented as hard-coded logic (e.g., an ASIC or other fixed-function integrated circuit) or programmable logic (e.g., a programmable logic device) performing the described functions. In other embodiments, the MPU 108 is implemented as some combination of an instruction execution processor and hard-coded or programmable logic.

[0019] MPU 108 operates to perform its various page management operations in response to commands from OS / HV 110 or independently of any trigger commands from OS / HV 110. For illustration, the page allocation process of processing system 100 relies on the use of at least one free list 132, which identifies which physical pages 120 of one or more memories 106 are “free”; that is, available for allocation to the corresponding virtual pages. In some embodiments, MPU 108 operates independently to periodically or otherwise repeatedly traverse the page table 126 of each page table structure 124 to identify those unused pages 120 (e.g., not yet referenced and not containing modified data) and mark any such pages 120 as free in the free list 132. In other embodiments, MPU 108 performs a page table traversal in response to a command from OS / HV 110, and this command may specify that only the identified page table structures 124 are “traversed” for free list analysis. As another example described in more detail below, MPU 108 generates a list of candidate pages for page migration between corresponding memories 106 and provides this list to OS / HV 110. OS / HV 110 then selects which pages to migrate and controls the migration of the selected pages. In other embodiments, MPU 108 identifies the pages to migrate and then performs the actual page migration independently of OS / HV 110, making the resulting page migration transparent to OS / HV 110. As yet another example, in some embodiments, while MPU 108 traverses page table 126, MPU 108 operates to collect and analyze or otherwise manipulate various page statistics or other analytical data (“analyze page data 134”) of page 120, such as the number or ratio of modified pages to unmodified pages. In some implementations, the MPU 108 operates independently of instructions from the OS / HV 110 to collect and process the data, while in other implementations, the data collection process of the MPU 108 is triggered by a command from the OS / HV 110, which may also specify which types of data to collect and analyze.

[0020] Regardless of whether a specific page management operation performed by the MPU 108 is triggered by system software or independent of commands from the system software, in at least one implementation, such operations are performed according to one or more policies specified by the OS / HV 110. For illustration, the OS / HV 110 can set policies regarding the management of free lists of pages available for allocation, the types of page information available for collection, the selection of page migration candidates, and priority sorting, etc.

[0021] Communication of commands, data, policies, and other information and signaling between the main processor 102 and the MPU 108 can be performed in any of a variety of ways and combinations thereof. In some embodiments, the processing system 100 employs a set of one or more queues 136 (such as queues 136-1 and 136-2) in memory 106 to facilitate communication. For illustration, in one embodiment, queue 136-1 is implemented as an input queue for receiving commands, configuration information, and other data from the main processor 102 for access by the MPU 108, while queue 136-2 is implemented as an output queue for receiving analysis page data 134, updated free lists 132, etc., from the MPU 108 for access by the OS / HV 110. In other embodiments, a single queue 136 is used for both commands and information from the OS / HV 110 to the MPU 108, and vice versa, in which case the information “packet” includes an identifier of the destination (main processor or MPU), an identifier of the communication type (e.g., command, list, statistics, configuration data, etc.), etc. In other embodiments, different types of communication use different queues. For example, commands from the main processor 102 to the MPU 108 are inserted into one queue 136, and free lists 132 are inserted by the MPU 108 into another queue 136, etc. In addition to using memory-based queues or other memory-based data structures for passing commands, data, and information between the main processor 102 and the MPU 108, or as an alternative, in some embodiments, one or more buses or other interconnects extending between the main processor 102 and the MPU 108 are used for communication between the main processor 102 and the MPU 108. For example, the main processor 102 issues commands to the MPU 108 via a Peripheral Component Interconnect Fast (PCIE) bus, an inter-chip Global Memory Interconnect (xGMI) bus, or other interconnects, and the MPU 108 signals the result of the operation by issuing an interrupt via the same or different interconnects, while one or more queues 136 or other memory locations are used to buffer data or information associated with the command or interrupt.

[0022] While attempting to support the main processor 102, there is a risk that the MPU 108 and the main processor 102 may concurrently access the same memory pages, the same page tables or page table entries, the same TLB entries, etc. Therefore, in at least one embodiment, the MPU 108 operates in coordination with the main processor 102 to avoid such concurrent access attempts. In some embodiments, this includes using selectively asserted "flags" that ensure only one component is manipulating the corresponding memory component at any given time, thereby facilitating security or system integrity strategies, such as scheduling decisions that prevent conflicts. These "flags" are typically memory locations programmed with semaphore values ​​(e.g., mutexes or semaphores) such that when that memory location is set to a specified value, other processors avoid one or more types of memory management operations.

[0023] Figure 2 The implementation of MPU 108 is shown in more detail. In some implementations, MPU 108 includes one or more of the following: a page table traverser 202, a data aggregation / reporting module 204, a PTE management module 206, and a page migration module 208. As described above, these components can be implemented at MPU 108 via corresponding instructions executed by a processor implementing MPU 108, via hard-coded or programmable logic, or a combination thereof. Page table traverser 202 operates to traverse page tables 126 of page table structures 124 currently residing in one or more memories 106. To this end, page table traverser 202 implements logic similar to that found in page table traversal components in a conventional MMU, similarly using any of a variety of conventional or proprietary page table traversal algorithms to traverse the page tables. However, while a conventional MMU attempts to actually perform a virtual-to-physical address translation when performing page table traversal, page table traverser 202 does not need to perform such translation, but instead traverses the entire page table and examines the contents of each PTE contained therein. Additionally, while conventional MMUs are typically limited to traversing only the page tables of the current process / context, in some implementations, the page table traverser 202 is not limited to this, but instead traverses some or all of the page tables 126 of the process / context that have page table structures 124 residing in memory 106. For illustration, the page table traverser 202 implements an array storing the CR3 values ​​for each process / context, and selects a CR3 value to identify the top-level table of the page table structure 124 of the process / context associated with that CR3 value, traverses the page tables of the page table structure 124, and when complete, selects the next CR3 value in the array and restarts the page table traversal process of the page table structure 124 indexed by the newly selected CR3 value. See below for reference. Figure 4 A more detailed description of the page table traversal process.

[0024] While page table traverser 202 traverses page table 126 of the selected page table structure 124, data aggregation / reporting module 204 operates to collect PTE data regarding page table 126. This collected data is aggregated or otherwise analyzed at one or more granular levels, such as for the entire memory subsystem 104, per memory, per region, per page, etc. For illustration, data aggregation / reporting module 204 determines the number of modified (i.e., "dirty") pages or the average number of modified pages across multiple memory regions of one of the memory systems 106 based on per region. Data aggregation / reporting module 204 further operates to provide a representation of the captured / analyzed data to main processor 102 as analyzed page data 134. PTE management module 206 operates to manage page table 126 itself using the data collected by data aggregation / reporting module 204. This includes, for example, modifying the status / attribute field of the PTE in page table 126, marking pages as candidates for page migration, detecting and reporting errors in page table 126, identifying and handling orphaned pages, moving pages into and out of free list 132, updating TLB 130 to reflect changes in page position and status, and identifying pages for power tuning purposes, etc. See below for reference. Figure 4 Further details regarding the operation of modules 204 and 206 are described.

[0025] In some implementations, the memory subsystem 104 has a non-uniform memory access (NUMA) configuration, where the main processor 102 accesses different memories 106 at different speeds. In some implementations, this difference in access time is at least partly based on the implementation of different types of memories. For example, one or more memories 106 are volatile random access memory (RAM), while one or more other memories 106 are flash memory or other non-volatile memories. This architectural difference may also be a result of different memory technologies. For example, one memory implements dynamic RAM (DRAM) technology, while another memory 106 implements static RAM (SRAM) technology, or one memory is based on dynamic data rate 2 (DDR2) DRAM, while another memory is based on dynamic data rate 4 (DDR4) memory. Other contributing factors to the difference in access speed include, for example, differences in clock speed, differences in distance to the main processor 102, differences in bus width, etc. Furthermore, in addition to or instead of differences in access time, different memories 106 typically offer different advantages and disadvantages. For example, some types of memory offer slower access times but provide superior storage capacity or superior power consumption, while other types of memory may offer faster access times but may be susceptible to write wear and other degradation proportional to their use.

[0026] Therefore, in at least one embodiment, the processing system 100 utilizes page migration to opportunistically identify situations where moving an allocated page 120 from one memory 106 to another memory 106 provides advantages (whether it be access speed, reduced power consumption, freeing up space for additional pages in faster memory, reduced write wear, or other aspects). To this end, while the page table traverser 202 traverses the page table 126, the page migration module 208 operates to identify whether the page 120 associated with the currently accessed and evaluated PTE is a candidate for page table migration based on any of a variety of considerations, such as information from the PTE, indications from the OS / HV 110, or data collected during previous page table traversals. In response to identifying page 120 as a candidate for page migration, in some embodiments, the page migration module 208 modifies the associated PTE to mark page 120 as a page migration candidate, or in other embodiments, adds the identifier of page 120 to a migration candidate list 138 maintained in the memory 106 of the storage subsystem 104. Figure 1 In some implementations, a migration candidate list 138 is available to the OS / HV 110, and the OS / HV 110 selects pages to migrate from the migration candidate list 138 and then oversees the page migration for each page thus selected. In other implementations, the MPU 108 is authorized to handle page migrations autonomously without involving the OS / HV 110, and therefore the page migration module 208 selects pages to migrate and then uses a DMA engine (not shown) implemented at the MPU 108 or alternatively uses the DMA engine 118 of the main processor 102 to indicate the page migration (it should be noted that, typically, the DMA engine 118 operates to perform memory operations, including data movement, without directly involving the OS / HV 110). References below... Figure 5 The page migration process used in MPU 108 is described in more detail.

[0027] Figure 3An example format of the PTE for page table 126 according to at least one embodiment is shown. As described above, the last level of the hierarchical page table structure 124 or other page table structure 124 includes multiple page tables 126, each page table 126 having multiple PTEs 302, such as PTEs 302-1 to 302-N shown. Each valid PTE 302 corresponds to an allocated page 120 residing in memory 106 and contains various information about the corresponding page 120. For illustration, PTE 302 includes a physical base address field 304 containing a base value representing the physical address associated with the corresponding page. PTE 302 also includes one or more status / attribute fields for the corresponding page 120. In at least one embodiment, some or all of the status / attribute fields of PTE 302 may be modified by MPU 108 based on a policy specified by OS / HV 110, based on data aggregated by data aggregation / reporting module 204, or a combination thereof.

[0028] The status / attribute fields of PTE 302 typically include one or more of the following: Existence (P) bit field 306, which stores a bit value indicating whether the corresponding page 120 actually exists in memory; Access (A) field 308, which stores a bit value indicating whether page 120 has been accessed; Dirty (D) field 310, which stores a bit value indicating whether page 120 has been modified since it was loaded into memory; and Global Page (G) field 312, which indicates whether the corresponding page 120 is a global page (wherein a process / context switch that causes an update to CR3 register 128 does not invalidate the TLB entry of the global page).

[0029] As described above, in some implementations, the memory subsystem 104 employs a NUMA architecture with multiple memory types (wherein this context, "type" refers to any of a variety of differences between memories 106, including architecture, technology, protocol, clock speed, distance, etc.), and therefore, in one implementation, the status / attribute field of PTE 302 includes a type field 314 that stores a value representing an identifier indicating the type of memory in which the corresponding page 120 resides. The type identifier identifies the corresponding type based on: architecture or memory architecture, such as volatile vs. non-volatile; DRAM vs. SRAM; specific technology, such as Flash vs. DDR SDRAM; memory access speed class (e.g., Class 1 (fastest), Class II (medium), Class III (slowest)); memory size class; power consumption level; write wear, etc. In other implementations, the memory type is represented in a separate data structure using, for example, the physical base address or other page identifier index in field 304. Similarly, in one implementation, PTE 302 includes a location (“LOC”) field 316 that stores a value specifying which memory 106 currently stores the corresponding page 120; that is, the “location” of page 120 in memory subsystem 104, where each memory 106 is assigned a corresponding location identifier.

[0030] As described above, in some embodiments, the processing system 100 employs page migration to move pages from one memory 106 to another memory 106 for purposes such as improving access speed, reducing power consumption, or reducing write wear. Therefore, in some embodiments, the PTE 302 includes one or both of a Ready to Migrate (RTM) field 318 and a migration priority field 320. The RTM field 318 stores a bit value indicating whether the corresponding page 120 is ready to migrate, while the migration priority field 320 stores a priority value used to weigh the selection of the corresponding page 120 for page migration. For example, a rarely accessed page may be marked for migration to a slower-accessed memory or "further" memory; in this case, the RTM field 318 is set as an assertion bit field, and the migration priority field 320 is set to a value indicating the priority of such migration based on, for example, how frequently the page is accessed, the priority of the data, or the envisioned type of migration. Page migration module 208 sets the priority value based on: policies or other instructions from OS / HV 110, such as policies that assign certain types of migrations a higher priority than others (e.g., prioritizing page migrations that reduce average page accesses per second over page migrations that reduce power consumption, and vice versa); and analysis of data collected by data aggregation / reporting module 204, such as assigning a higher page migration priority to the first page and a lower page migration priority to the second page when access to the first page is significantly more frequent than to the second page. In other embodiments, the RTM status and migration priority status of one or more sets of pages 120 are stored in one or more data structures in memory 106 and indexed using, for example, the physical base address or other identifier of the corresponding page.

[0031] Now go to Figure 4 According to some embodiments, a method 400 is described for the operation of an MPU 108 to provide memory page management operations that offload or enhance the conventional page management process provided by system software from the main processor 102. Method 400 includes a page table traversal process performed by a page table traverser 202, and PTE data collection, analysis, and reporting processes and a PTE management process performed by the data aggregation / reporting module 204 and PTE management module 206 of the MPU 108, respectively.

[0032] In at least one implementation, the aggregation, analysis, and reporting of page information, as well as the management of PTEs, are performed as part of a page table traversal process executed by page table traverser 202, such that when each PTE is encountered during page table traversal, that PTE is analyzed and any associated analysis page data 134 is updated. Therefore, the description of method 400 begins with a page table traversal process that sequentially or "traverses" each PTE (e.g., PTE 302) of each page table 126 of the identified page table structure 124. As described above, in some implementations, the base address of a given page table structure 124 is identified based on the PCID of the process / context represented by the page table structure 124. In one implementation, page table traverser 202 maintains a list of all associated PCIDs in an array and sequentially selects each PCID and performs a page table traversal on the page table structure 124 identified by that PCID, and upon completion, selects the next PCID in the sequence and performs a page table traversal on the page table structure 124 associated with that PCID, and so on. In this way, MPU 108 provides more comprehensive management of memory pages 120, but at the cost of lower responsiveness or less current information about the currently executing process / context. In other embodiments, page table traverser 202 traverses the page table structure 124 of the currently executing process / context, and when a context switch to the next process / context occurs, page table traverser 202 switches to traversing the page table structure 124 associated with the next process / context (and identified using, for example, a value loaded into CR3 register 128). This page table switching method with context switching, as described below, facilitates maintaining up-to-date page information for the current process / context, but at the cost of a less comprehensive evaluation of page information for all enabled processes / contexts.

[0033] In either method, the page table traversal process is initiated at block 402, where any page table structure 124 to be traversed is identified using a PCID selected from the PCID array or accessed from the CR3 register 128, depending on the pattern. The page table traversal process can be initiated by the OS / HV 110 via a command or other signal, or the MPU 108 can independently manage the page table traversal process, continuously looping through one or more page table structures 124 or initiating page table traversal in response to a timer or other trigger. With the initiation of page table traversal, at block 404, page table traverser 202 selects the next (or first) PTE 302 of page table structure 124. Figure 3 And access the selected PTE 302 from the corresponding page table 126.

[0034] For accessed PTE 302, at box 406, the data aggregation / reporting module 204 collects and aggregates or otherwise analyzes the information represented in PTE 302 based on the strategy set by OS / HV 110 and combines the results with one or more instances of analyzed page data 134. For illustration, as indicated by box 408, the data aggregation / reporting module 204 performs one or more statistical analyses on specified groups of PTE 302, which include, for example, all PTEs 302 associated with a process / context of a specified type of memory 106, a specific memory 106, a specific region of memory 106, or some combination thereof. An example of the statistical analysis performed includes maintaining a count of the number of analyzed PTEs representing pages 120 that have been accessed (as set in access field 308). Figure 3 (as indicated by ) and a list of all pages identified as having been accessed, the ratio of accessed to unaccessed pages or the ratio of accessed pages to total analyzed pages, etc. Another example maintains a count of the number of PTEs representing the number of pages 120 that have been modified in the analysis (as set in dirty field 310). Figure 3 (as indicated), and a list of all pages 120 identified as having been modified, the ratio of dirty pages to clean pages or dirty pages to the total number of pages, etc.

[0035] As indicated in box 410, the analysis performed at box 406 includes data aggregation / reporting module 204 identifying one or both of the memory type (e.g., DRAM, SRAM, non-volatile RAM (NVRAM), etc.) and finding the memory location of the corresponding page 120 (e.g., an identifier for a specific memory 106), and then configuring the type field 314 and location field 316 of PTE 302. Figure 3 One or both of these can be used to reflect the information, or the information can be used to populate the corresponding field of the instance of the analyzed page data 134. As indicated in box 412, the analysis performed at box 406 also includes the identification of the most recently used (MRU) and least recently used (LRU) pages 120 in an implementation in which PTE 302 includes a last access timestamp field or a similar attribute, wherein this determination is made, for example, by comparing the last access timestamp of the accessed PTE 302 with the most recently accessed and least recently accessed timestamps encountered so far in the ongoing page table traversal.

[0036] As yet another example, box 414 illustrates the implementation of the analysis performed at box 406, where the data aggregation / reporting module 204 constructs and maintains a histogram or other statistical representation of memory page usage based on each page, each group of pages, each memory region, or each memory. For illustration, as described below, in some implementations, the PTE management module 206 operates to clear the access field 308 of PTE 302 each time PTE 302 is accessed during a page table traversal iteration, or based on some other strategy specified by OS / HV 110. Therefore, if the access field 308 is set on the next access to PTE 302, this indicates that the page has been accessed or "used," and thus the data aggregation / reporting module 206 reflects this use by incrementing the usage metric or other page granularity for the corresponding page. Then, a histogram of page usage counts for the specified group of pages is compiled and updated with each PTE access. Similarly, a histogram or other representation of dirty page frequency or similarity metrics is generated.

[0037] In an implementation of the page migration scheme in processing system 100, the analysis process in block 406 includes page migration candidate eligibility analysis, represented by block 416. To this end, data aggregation / reporting module 204 evaluates statistical and other data related to page 120 collected during one or more page table traversal iterations to identify whether page 120 is a page migration candidate, and if so, sets a migration priority for page 120. For illustration, data aggregation / reporting module 204 analyzes collected memory page usage data (at block 414) to determine the relative access frequency to the corresponding page 120, and if page 120 has a relatively high access frequency but is currently located in relatively slow-access memory 106, then page 120 is identified as a high-priority candidate for page migration to the faster-access memory 106. As another example, the statistical analysis represented by box 408 may indicate a subset of pages 120 of memory 106 that are accessed less frequently than the average frequency of page accesses to memory 106, and therefore each page 120 in this subset is identified as a candidate for migration to a different memory 106, which can be used to remain in a low-power state for an extended period due to the low access frequency and the priority of such migration set according to the policy specified by OS / HV 110. As described above, in some embodiments, the MPU 108 sets the candidate eligibility and migration priority of pages 120 for page migration by configuring the RTM field 318 and migration priority field 320 of the accessed PTE 302, respectively. In other embodiments, the data aggregation / reporting module 204 maintains a data structure containing identifiers of pages 120 identified as candidates for page migration and corresponding identifiers of their determined migration priorities.

[0038] In some implementations, access to PTE 302 at box 404 triggers PTE management module 206 to perform one or more PTE management operations on the accessed PTE 302 at box 420. These operations include one or more PTE management operations conventionally performed by the OS / HV via the MMU; additional PTE management operations as extensions or additions to regular PTE management capabilities; or combinations thereof. For illustration, as indicated by box 422, the management operations in box 420 include setting or clearing various status / attribute bits (or fields) of the accessed PTE 302. For example, if access field 308 is set when accessing PTE 302, the field is cleared so that data aggregation / reporting module 204 can determine whether the corresponding page 120 has been accessed again after the last page table traversal iteration. Similarly, dirty field 310 is set or cleared when PTE 302 is accessed according to a policy set by OS / HV 110. As another example, as shown in box 424, the PTE management module 206 filters the statistics generated at box 406 based on a policy from the OS / HV 110. For illustration, this policy may specify that certain regions or the entire specified memory 106 should be excluded from the analysis, and the PTE management module 206 signals the data aggregation / reporting module 204 to avoid including any analysis data collected from the corresponding PTE 302. As shown in box 426, the PTE management operations performed at box 420 include the management of orphaned pages.

[0039] As another example, as illustrated in box 428, the PTE management module 206 detects and, in some cases, corrects errors in PTE 302 or its corresponding page table 126. For illustration, if PTE 302 sets its dirty field 310 but its access field 308 is cleared, this indicates an inconsistency because if the corresponding page 120 has been modified, it has by definition also been accessed. In response to detecting this error, in some embodiments, the PTE management module 206 attempts to correct the error, such as by accessing each memory location within the page to determine if a memory location has been modified, and if at least one modified memory location has been identified within the page, the PTE management module 206 determines that access field 308 has been incorrectly cleared and therefore sets access field 308. However, if no modified memory location has been identified within the page, the PTE management module 206 determines that dirty field 310 has been incorrectly set and therefore corrects PTE 302 by clearing dirty field 310. In other implementations, the PTE management module 206 identifies PTE 302 or page table 126 that appears to be faulty but does not attempt to correct certain types of errors (as indicated by the policy), and for such errors, generates a list of potentially corrupted PTE 302 / page table 126 and provides this list to the OS / HV 110 for processing and correction, or alternatively issues an interrupt or other exception to trigger the OS / HV 110 to process the detected errors.

[0040] As described above, page allocation in processing system 100 depends on the use of one or more free lists 132, which specify "free" (i.e., available for allocation) physical pages in memory subsystem 104. As shown in box 430, in one embodiment, PTE management module 206 operates to manage free list 132. This includes, for example, using LRU / MRU information, memory page usage information, and other statistics collected by data aggregation / reporting module 204 to identify pages 120 that have not been recently referenced or have been referenced relatively infrequently and do not contain modified data, and marking these pages as available for allocation and injecting them into free list 132 according to a specified strategy. Furthermore, to ensure page security, MPU 108 uses its own DMA capabilities or DMA engine 118 to overwrite a physical page in memory 106 with a specified value (e.g., all zeros) when the physical page is available on free list 132.

[0041] In some implementations, MPU 108 maintains a free list 132, but OS / HV 110, together with MMU 114, uses pages marked as available in free list 132 to allocate pages. However, in other implementations, PTE management module 206 of MPU 108 operates to perform some or all of the page allocations on behalf of OS / HV 110 using free list 132. For illustration, when a page allocation is needed, MMU 114 signals MPU 108, and MPU 108 then selects an available physical page from free list 132 for allocation, updates page table structure 124 to include the PTE 302 of the selected page in the appropriate page table 126, and signals MMU 114 that the page has been allocated and page table 126 has been updated accordingly.

[0042] As described above, the main processor 102 typically employs TLB 130 to provide fast PTE access for virtual-to-physical address translation of a small subset of PTEs in page table structure 124, where a PTE in TLB 130 typically represents the most recently accessed or most frequently accessed page 120. Therefore, when the MPU 108 modifies a PTE 302 in page table structure 124 that has a copy stored in TLB 130, as shown in box 432, the PTE management module 206 updates TLB 130 to reflect the change made to the corresponding PTE 302 in page table structure 124. For example, if page 120 is moved to free list 132, the MPU 108 accesses TLB 130 to invalidate the corresponding copy of PTE 302 in TLB 130. As another example, if the status / attribute field has been modified, or the page has been migrated to a different memory 106 and therefore has a new physical base address, the MPU 108 accesses a copy of the PTE in the TLB 130 to make those same changes. As yet another example, if the MPU 108 is used to allocate a page, the MPU 108 also updates the TLB 130 to include the entry for the allocated page, depending on the policy specified by the OS / HV 110.

[0043] In some implementations, the processing system 100 has the capability to employ power tuning through the selective activation and deactivation of various memories 106 of the memory subsystem 104. Therefore, as illustrated in block 434, the PTE management module 206 independently or at the instruction of the OS / HV 110 identifies situations where such power tuning may be employed, and then directly controls the memory 106 to enter and exit a data-retaining power-down state, or provides a suggestion to the OS / HV 110, which then decides whether to implement power management for the memory 106. For illustration, the PTE management module 206 determines from the analyzed page data 134 generated by the data aggregation / reporting module 204 that a majority or all of the pages 120 of a particular memory 106 are accessed relatively infrequently, and if a policy is met, the PTE management module 206 directly puts the memory 106 into a data-retaining low-power state or provides a suggestion to the OS / HV 110 to do so. Additionally, when doing so, the PTE management module 206 configures the PTE 302 of page 120 of memory 106 with a read-only bit, causing an attempt to write to memory 106 to result in a page fault 110, which is intercepted by the OS / HV and causes the OS / HV 110 (or MPU 108) to restore memory 106 to full power.

[0044] After appropriate analysis and management operations have been performed using the accessed PTE 302 at boxes 406 and 420 respectively, at box 436, the data aggregation / reporting module 204 determines whether a report trigger has occurred. This report trigger may include, for example, a signal from the OS / HV 110 requesting an update to page information, a timer expiration, the page table traverser 202 reaching the last PTE 302 of the page table structure 124, a context switch initiation, etc. If a trigger exists, at box 438, the data aggregation / reporting module 204 provides information related to the page table traversal, analysis, and management performed by the MPU 108 since the last report instance. This information includes, for example, a representation of the analyzed page data 134, an updated free list 132, page migration recommendations, page table error reports, etc. The OS / HV 110 then takes action on the information in the report, such as attempting to correct identified page table errors, allocating pages based on the updated free list 132, initiating page migrations based on recommendations, etc. In other implementations, OS / HV 110 estimates information and then, based on its estimates, instructs MPU 108 to perform one or more page management actions, such as instructing MPU 108 to perform certain page migrations or correct certain page table errors. In the absence of any reporting request, or concurrently with the reporting process, method 400 returns to box 404, where page table traverser 202 selects and accesses the next PTE 302 in the currently traversed page table structure 124, and performs the next iteration of method 400 for this selected and accessed PTE.

[0045] Figure 5 An example method 500 for page migration within a memory subsystem 104 at least partially supported by an MPU 108, according to some embodiments, is shown. Method 500 is initiated at block 502, wherein the migration is initiated via a page migration candidate list or via the RTM field 318 of the corresponding PTE 302. Figure 3 The page migration module 208 selects candidate pages 120 marked for page migration based on the page migration guidelines or other strategies provided by the OS / HV 110 to determine whether candidate pages 120 should actually be migrated to another memory 106. This analysis includes, for example, estimating page migration priorities based on the weight or hierarchy of page migration types (e.g., page migration for speed takes precedence over page migration for load balancing, page migration for load balancing takes precedence over page migration for wear leveling, etc.) and estimating the estimated benefits obtained through page migration (e.g., migrating a page with page access frequency X to faster memory is more likely to provide a performance benefit than migrating a page with page access frequency Y, where X >> Y). If the analysis results in avoiding the migration of candidate pages, in some embodiments, at box 506, the page migration candidate qualification of the selected page 120 is removed, such as by clearing the RTM field 318 of the corresponding PTE entry 302 or removing page 120 from the page migration candidate list.

[0046] Otherwise, if a page migration is decided, at box 508, the data at the original location of page 120 stored in source memory 106 is copied to an identified location in target memory 106, wherein target memory 106 is selected based on any of a number of factors related to the motivation for page migration, such as selecting memory 106 with faster access times when the goal of page migration is to improve performance, or selecting memory 106 with larger storage capacity when the motivation is to free up space in faster source memory 106. Then, for security purposes, the original page location is overwritten with a specified data pattern.

[0047] Before, during, or after transferring page 120 via copied page data, at box 510, page migration module 208 accesses the dirty field 310 of PTE 302 associated with the migrated page 120 to determine if it contains any modified data. If so, at box 512, page migration module 208 uses the DMA engine of MPU 108 or the DMA engine 118 of main processor 102 to perform a write-back operation to store the modified page to the mass storage device from which the page originated.

[0048] At box 514, PTE management module 206 updates the PTE 302 associated with the migrated page to reflect its new location in target memory 106. This update includes, for example, updating the physical base address field 304. Figure 3 To reflect the new location, update type field 314 ( Figure 3 ) and location field 316 ( Figure 3 The PTE management module 206 updates the TLB 130 in a similar manner if a copy of PTE 302 also exists in TLB 130 and is valid. Since the migration of page 120 frees up a physical page in source memory 106 and occupies a physical page in target memory 106, at block 516, the page migration module 208 updates the free list 132 to remove the new location of the migrated page 120 from the free list 132 and inject the old location of the migrated page 120 into the free list 132. Additionally, in some embodiments, at block 518, the data aggregation / reporting module...

[0049] Operation 204 updates any portion of the analytics page data 134 affected by page migration, such as by transferring statistics associated with the migrated page from the portion related to source memory 106, source memory area or other source group to the portion related to target memory 106, target memory area or other target group.

[0050] In some implementations, the devices and techniques described above are implemented in systems including one or more integrated circuit (IC) devices (also known as integrated circuit packages or microchips), such as those referenced above. Figures 1 to 5 The MPU 108 is described. Electronic design automation (EDA) and computer-aided design (CAD) software tools are commonly used to design and fabricate these IC devices. These design tools are typically represented as one or more software programs. The one or more software programs include code executable by a computer system to manipulate the computer system to operate a circuit representing one or more IC devices to perform at least a portion of a process for designing or adapting a manufacturing system to manufacture the circuit. The code includes instructions, data, or a combination of instructions and data. Software instructions representing the design or manufacturing tools are typically stored in a computer-readable storage medium accessible by a computing system. Similarly, code representing one or more stages of the design or fabrication of the IC device is stored in the same or different computer-readable storage media and is accessed from the same or different computer-readable storage media.

[0051] Computer-readable storage media include any non-transitory storage medium or combination of non-transitory storage media that can be accessed by a computer system during use to provide instructions and / or data to the computer system. Such storage media include, but are not limited to, optical media (e.g., compact discs (CDs), digital universal discs (DVDs), Blu-ray discs), magnetic media (e.g., floppy disks, magnetic tapes, or magnetic hard disks), volatile memory (e.g., random access memory (RAM) or cache), non-volatile memory (e.g., read-only memory (ROM) or flash memory), or microelectromechanical systems (MEMS) based storage media. In some embodiments, the computer-readable storage medium is embedded in a computing system (e.g., system RAM or ROM), fixedly attached to a computing system (e.g., a magnetic hard disk), removably attached to a computing system (e.g., an optical disc or a flash memory based on a universal serial bus (USB)), or coupled to a computer system via a wired or wireless network (e.g., a network accessible storage device (NAS)).

[0052] In some implementations, certain aspects of the techniques described above are implemented by one or more processors of a processing system executing the software. The software includes one or more sets of executable instructions stored or otherwise tangibly embodied on a non-transitory computer-readable storage medium. The software includes instructions and certain data that, when executed by one or more processors, instruct one or more processors to perform one or more aspects of the techniques described above. Non-transitory computer-readable storage media include, for example, disk or optical disk storage devices, solid-state storage devices (such as flash memory), caches, random access memory (RAM), or one or more other non-volatile memory devices. The executable instructions stored on the non-transitory computer-readable storage medium are implemented, for example, in source code, assembly language code, object code, or other instruction formats that are interpreted or otherwise executable by one or more processors.

[0053] According to one aspect, a system includes a main processor coupled to a memory subsystem having at least one memory. The main processor executes system software employing memory address translation based on one or more page tables stored in the memory subsystem. The system also includes a coprocessor coupled to the memory subsystem. The coprocessor performs iterations of page table traversal throughout one or more page tables maintained for the memory subsystem, and performs one or more page management operations on behalf of the system software and based on the page table traversal iterations. In some embodiments, the one or more page management operations include: the coprocessor generating analytical page data representing memory pages represented by at least a subset of page table entries accessed by the coprocessor during page table traversal, the analytical page data being based on values ​​at one or more fields of the page table entries; and the analytical page data including at least one of: a count of pages having a specified state or attribute, a statistical representation of pages having a specified state or attribute, or a list of pages identified as having a specified state or attribute. In some implementations, one or more page management operations further include at least one of the following: operations by which a coprocessor maintains a free list of pages available for allocation based on analyzing page data; operations by which a coprocessor identifies at least one page as a candidate for page migration based on analyzing page data; operations by which a coprocessor determines at least one of a Most Recently Used (MRU) page or a Least Recently Used (LRU) page based on analyzing page data; and operations by which a coprocessor identifies a memory of the memory subsystem as a candidate to enter a low-power state based on analyzing page data.

[0054] In some implementations, one or more page management operations include at least one of the following: an operation by which a coprocessor modifies one or more fields of a page table entry; or an operation by which a coprocessor invalidates a page table entry or inserts the page table entry into the page table. One or more page management operations may also include an operation by which the coprocessor modifies the main processor's translation backstop buffer in response to the modification of one or more fields of a page table entry or in response to invalidating a page table entry or inserting the page table entry into the page table.

[0055] In some implementations, one or more page management operations include the coprocessor estimating page table entries or errors in the page table accessed during page table traversal. In some implementations, one or more page management operations include the coprocessor migrating a page from one memory of the memory subsystem to another memory of the memory subsystem. In some implementations, one or more page management operations include at least one of the following: selecting pages to be included in a free list of pages available for allocation based on page table entries of pages accessed during page table traversal; or allocating pages from the free list based on a request for page allocation from the main processor. In some implementations, system software specifies one or more policies for page management to the coprocessor, and the coprocessor performs one or more page management operations based on the one or more policies. In some implementations, the coprocessor performs at least one of one or more page management operations in response to a command from the system, or the coprocessor is configured to perform at least one of one or more page management operations independently of the system software. In other implementations, the coprocessor is configured to perform at least one of one or more page management operations in coordination with the system software using one or more flags to prevent concurrent access attempts by both the main processor and the coprocessor. In some implementations, the coprocessor has limited general processing power compared to the main processor.

[0056] According to another aspect, a coprocessor may be coupled to a main processor and to a memory subsystem having at least one memory. The coprocessor performs an iteration of page table traversal of a set of one or more page tables, and generates analytical page data representing the set of one or more page tables based on each page table entry in at least a subset of page table entries accessed during the page table traversal. In some embodiments, the analytical page data includes at least one of the following: a count of pages having a specified state or attribute, a statistical representation of pages having a specified state or attribute, or a list of pages identified as having a specified state or attribute.

[0057] According to another aspect, a method for page management in a processing system is provided, the processing system having a main processor, a coprocessor, and a memory subsystem having at least one memory. The method includes: executing system software at the main processor, wherein the execution of the system software includes performing address translation based on one or more page tables maintained in the memory subsystem; performing an iteration of page table traversal through the one or more page tables at the coprocessor; and performing one or more page management operations at the coprocessor on behalf of the system software and based on the iteration of the page table traversal.

[0058] It should be noted that not all activities or elements described in the general description above are required, and a specific activity or part of the apparatus may not be required. Furthermore, one or more additional activities or elements may be performed in addition to those described. Additionally, the order in which the activities are listed is not necessarily the order in which they are performed. Furthermore, the concepts have been described with reference to specific embodiments. However, those skilled in the art will understand that various modifications and changes may be made without departing from the scope of this disclosure as set forth in the appended claims. Therefore, this specification and drawings are to be regarded as illustrative rather than restrictive, and all such modifications are intended to be included within the scope of this disclosure.

[0059] The benefits, other advantages, and solutions to the problems have been described above with respect to specific embodiments. However, the benefits, advantages, solutions to the problems, and any features that may cause any benefit, advantage, or solution to the problem to appear or become more prominent should not be construed as key, essential, or necessary features of any or all claims. Furthermore, the specific embodiments disclosed above are merely illustrative, as the disclosed subject matter can be modified and practiced in different but equivalent ways that would be obvious to those skilled in the art benefiting from the teachings herein. No limitation is intended to be made on the details of the constructions or designs shown herein other than those described in the appended claims. Therefore, it is apparent that the specific embodiments disclosed above may be altered or modified, and all such variations are considered to be within the scope of the disclosed subject matter. Therefore, the protection sought herein is as set forth in the appended claims.

Claims

1. A processing system comprising: a host processor, the host processor being couplable to a memory subsystem having at least one memory, the host processor being configured to execute system software that employs memory address translations based on one or more page tables stored in the memory subsystem; and a co-processor, the co-processor being couplable to the memory subsystem, the co-processor being configured to perform iterations of a page table walk through one or more page tables maintained for the memory subsystem, and to perform, on behalf of the system software and based on the iterations of the page table walk, one or more page management operations including maintenance of a free list of pages available for allocation.

2. The processing system of claim 1, wherein the one or more page management operations include: an operation of the co-processor to generate analytics page data for memory pages represented by at least a subset of page table entries accessed by the co-processor during the page table walk, the analytics page data being based on values at one or more fields of the page table entries.

3. The processing system of claim 2, wherein the analytics page data includes at least one of a count of pages having a specified state or attribute, a statistical representation of pages having the specified state or attribute, or a list of pages identified as having the specified state or attribute.

4. The processing system of claim 2, wherein the one or more page management operations further include at least one of: an operation of the co-processor to identify at least one page as a candidate for page migration based on the analytics page data; an operation of the co-processor to determine at least one of a most recently used (MRU) page or a least recently used (LRU) page based on the analytics page data; and an operation of the co-processor to identify memory of the memory subsystem as a candidate for entering a low power state based on the analytics page data.

5. The processing system of claim 1, wherein the one or more page management operations include at least one of: an operation of the co-processor to modify one or more fields of a page table entry; or an operation of the co-processor to invalidate a page table entry or to insert the page table entry into a page table.

6. The processing system of claim 5, wherein the one or more page management operations include: an operation of the co-processor to modify a translation lookaside buffer of the host processor in response to modification of one or more fields of a page table entry or in response to invalidating a page table entry or inserting the page table entry into a page table.

7. The processing system of claim 1, wherein the one or more page management operations include: an operation of the co-processor to estimate errors in page table entries or page tables accessed during the page table walk.

8. The processing system of claim 1, wherein the one or more page management operations include: an operation of the co-processor to migrate a page from one memory of the memory subsystem to another memory of the memory subsystem.

9. The processing system of claim 1, wherein the one or more page management operations include at least one of: selecting pages to include in a free list of the pages available for allocation based on page table entries of the pages accessed during the page table walk; or allocating pages from the free list based on requests for page allocation from the host processor.

10. The processing system of any of claims 1 to 9, wherein: the system software is configured to specify one or more policies for management of pages to the co-processor; and the co-processor is configured to perform the one or more page management operations based on the one or more policies.

11. The processing system of any of claims 1 to 9, wherein: the co-processor is configured to perform at least one of the one or more page management operations in response to a command from the system software.

12. The processing system of any of claims 1 to 9, wherein: the co-processor is configured to perform at least one of the one or more page management operations independently of the system software.

13. The processing system of any of claims 1 to 9, wherein: the co-processor is configured to perform at least one of the one or more page management operations in coordination with the system software using one or more markers to prevent concurrent access attempts by both the host processor and the co-processor.

14. The processing system of any of the preceding claims, wherein the co-processor has limited general processing capabilities compared to the host processor.

15. A co-processor, the co-processor being couplable to a host processor and to a memory sub-system having at least one memory, the co-processor being configured to: performing an iteration of a page table walk of a set of one or more page tables; and generate analytics page data representing the set of one or more page tables based on each page table entry of at least one subset of page table entries of the one or more page tables accessed during the page table walk; and maintain a free list of pages available for allocation based on iterations of the page table walk.

16. The co-processor of claim 15, wherein the analytics page data comprises at least one of: a count of pages having a specified state or attribute, a statistical representation of pages having the specified state or attribute, or a list of pages identified as having the specified state or attribute.

17. The co-processor of claim 15 or 16, wherein the co-processor is further configured to perform one or more page management operations, the one or more page management operations comprising at least one of: an operation to identify at least one page as a candidate for page migration based on the analytics page data; an operation to determine at least one of a most recently used (MRU) page or a least recently used (LRU) page based on the analytics page data; an operation to identify memory of the memory sub-system as a candidate to enter a low power state based on the analytics page data; an operation to modify one or more fields of a page table entry; an operation to invalidate a page table entry or to insert the page table entry into a page table; modifying operation of a translation lookaside buffer of the host processor based on at least one of: a corresponding modification to one or more fields of a page table entry; or invalidating or inserting a page table entry into a page table; or estimating an error of a page table entry or a page table accessed during the page table walk.

18. A method of page management in a processing system having a host processor, a co-processor, and a memory sub-system having at least one memory, the method comprising: executing system software at the host processor, wherein execution of the system software includes performing address translations based on one or more page tables maintained in the memory sub-system; performing, at the co-processor, iterations of a page table walk through the one or more page tables; and performing, at the co-processor on behalf of the system software and based on the iterations of the page table walk, one or more page management operations including maintaining a free list of pages available for allocation.

19. The method of claim 18, wherein the one or more page management operations include: generating analytics page data for memory pages represented by at least a subset of page table entries accessed by the co-processor during the page table walk, the analytics page data based on values at one or more fields of the page table entries.

20. The method of claim 19, wherein the one or more page management operations further include at least one of: identifying at least one page as a candidate for page migration based on the analytics page data; determining at least one of a most recently used (MRU) page or a least recently used (LRU) page based on the analytics page data; or identifying memory of the memory sub-system as a candidate to enter a low power state based on the analytics page data.

21. The method of claim 18, wherein the one or more page management operations include at least one of: modifying one or more fields of a page table entry; invalidating a page table entry of a page table; inserting a page table entry into a page table; modifying a translation lookaside buffer of the host processor in response to modifying one or more fields of a page table entry or in response to invalidating or inserting the page table entry into a page table; estimating an error of a page table entry or a page table accessed during the page table walk; migrating a page from one memory of the memory sub-system to another memory of the memory sub-system; selecting a page to include in a free list of pages available for allocation based on a page table entry of the page accessed during the page table walk; or allocating a page from the free list based on a request for a page allocation from the host processor.

22. The method of any one of claims 18 to 21, the method further comprising: specifying, by the system software to the co-processor, one or more policies for management of pages; and wherein the one or more page management operations are performed by the co-processor based on the one or more policies.

23. The method of any one of claims 18 to 21, wherein: Performing the one or more page management operations includes performing at least one of the one or more page management operations in response to a command from the system software.

24. The method of any of claims 18-21, wherein: Performing the one or more page management operations includes performing at least one of the one or more page management operations independently of a command from the system software.

Images