Sleep / Wake-Up Performance Enhancement for Concurrent Address Translation Table Walks

Abstract

The memory address translation system includes a translation requester module configured to provide translation requests from virtual addresses to real addresses in physical memory. A translation cache module is configured to receive translation requests from the translation requester module. A sleep and wake control module is configured to compare the received VA with the VA's of all currently active table walks of the table walk machines. Upon determining that an address match exists in a given table walk machine, the translation request is sent to the translation requester module along with an identification number (ID) for putting to sleep. Each table walk machine is configured to provide a wake-up signal with the ID to the translation requester module upon completion of its translation level, thereby triggering the wake-up and processing of currently sleeping translation requests and providing parallel translation table walks.

Description

[Technical Field]

[0001] The present disclosure relates generally to computer systems, and more particularly to managing memory tables in a processing system. [Background technology]

[0002] In recent years, operating systems for computing platforms use a combination of hardware and software to map memory addresses used by programs, sometimes called virtual addresses, to physical addresses in the computer's memory. In this way, main storage appears as a uniform segment in a contiguous address space. The operating system manages the virtual address space and the allocation of real (physical) memory to virtual memory. Address translation hardware in the processor, sometimes called a memory management unit (MMU), translates virtual addresses to physical addresses. Software in the operating system provides a virtual address space that is larger than the capacity of real memory, thereby allowing it to reference more memory than is physically present on the computing platform. By using virtual memory, software can use more memory than may be physically available. Virtual memory simplifies application programming by disguising physical memory fragmentation.

[0003] Current computing systems use different address translation mechanisms based on the type of operating system being used. To support multiple computer system environments, address translation hardware should support multiple page sizes when translating from a virtual address (VA) to a real (i.e., physical) address (RA). As used herein, an effective address (EA) is the address that a program sees; a virtual address (VA) is the address used by the OS; and a real address (RA) is the actual memory hardware address.

[0004] When finally translating an EA or VA into an RA, the processor typically performs the time-intensive process of walking a translation table to generate the correct address so that the appropriate memory address can be accessed. A page table is where the operating system stores its mappings from virtual addresses (VAs) to physical addresses, and each mapping is also known as a page table entry (PTE). The results of the translation walk are typically cached for later use. However, the time-intensive table walk process must first be performed, which can involve many memory reads and cache accesses and can stall the progress of a hardware thread or even the entire processor core. Summary of the Invention

[0005] In various embodiments, methods, systems, and computing devices for providing memory address translation in a multiple page size environment include receiving a translation request from a virtual address (VA) to a real address (RA) in physical memory. The received VA is compared to the VA' of all currently active table walks of a group of table walk machines. Upon determining, based on the comparison, that an address match exists within a given table walk machine of the group of table walk machines, the translation request is sent to a translation requesting module along with an identification number (ID) to be put to sleep. Upon determining that the given table walk machine has completed its translation level, a wake-up signal having the ID is sent to the translation requesting module to trigger wake-up and processing of the put to sleep translation request. The table walk of the VA of the translation request having the ID is provided in parallel with one or more other table walks of other translation requests of the group of table walk machines.

[0006] In one embodiment, the step of comparing the received VA to the VA′ of the currently active table walk includes, for each currently active table walk: comparing virtual address bits of the received VA to a range of addresses at a translation level of the currently active table walk.

[0007] In one embodiment, for each active table walk, the state of the table walk (ie, the translation level) is used to determine the number of address bits to compare to determine if an address collision exists.

[0008] In one embodiment, comparing the received VA with the VA′ of the currently active table walk includes, for each currently active table walk, comparing a most significant bit (MSB) of the address up to the bit boundary of the largest supported page size.

[0009] In one embodiment, upon determining, based on the comparison, that no address match exists within a given table walk machine of the group of table walk machines, the translation request to be processed is sent directly by a table walk machine of the group of table walk machines.

[0010] In one embodiment, upon receiving the conversion request, the conversion cache module determines whether the conversion request for the VA has previously been successfully processed. Upon determining that the conversion request for the VA has not previously been successfully processed, the conversion request is sent directly to one or more table walk machines.

[0011] In one embodiment, the translation request includes at least one of a hashed page table (HPT) request, a segment table request, a non-nested radix request, or a nested radix request.

[0012] In one embodiment, the completed translation level is a level 1 radix tree directory base (RTDB), which is used as the base address of the first radix translation table.

[0013] In one embodiment, the next level given table walk machine is a page table entry (PTE), which is used to define the next range of translations. The next level can also be a page directory entry (PDE). Meanwhile, the PTE contains the physical address of the translation, and the PDE contains a radix tree directory base (RTDB), which is a base pointer to the next radix table. Both can be used to define address ranges for comparison.

[0014] The teachings herein provide for more efficient memory address translation that provides for parallel processing of translation requests. These and other features will become apparent from the following detailed description of illustrative embodiments thereof, which is to be read in connection with the accompanying drawings. [Brief explanation of the drawings]

[0015] The drawings are of exemplary embodiments. The drawings do not depict all embodiments. Other embodiments may be used in addition or instead. Details that may be obvious or unnecessary may be omitted to save space or for a more effective illustration. Some embodiments may be practiced with additional components or steps, or without all of the components or steps shown, or combinations thereof. When the same numeral appears in different drawings, it refers to the same or similar components or steps.

[0016] [Figure 1] FIG. 1 is a conceptual block diagram of a memory address translation system supporting multiple parallel table walks, consistent with an illustrative embodiment.

[0017] [Figure 2]FIG. 1 is a conceptual process flow diagram of memory address translation in a multiple page size environment, consistent with an example embodiment.

[0018] [Figure 3A] 10 is an exemplary sleep / wake parallel table walk, consistent with an exemplary embodiment.

[0019] [Figure 3B] 1 is a table of two virtual address translation requests processed by a system consistent with an exemplary embodiment.

[0020] [Figure 4] 1 is an exemplary process flow for memory address translation in a multiple page size environment, consistent with an exemplary embodiment.

[0021] [Figure 5] 1 provides a functional block diagram illustration of a computer hardware platform that may be used to host a memory address translation system.

[0022] [Figure 6] 1 illustrates a cloud computing environment, consistent with an illustrative embodiment.

[0023] [Figure 7] 1 illustrates abstraction model layers consistent with an illustrative embodiment. DETAILED DESCRIPTION OF THE INVENTION

[0024] [overview] In the following detailed description, numerous specific details are set forth by way of example in order to provide a thorough understanding of the relevant teachings. However, it should be apparent that the present teachings may be practiced without such details. In other instances, well-known methods, procedures, components, and / or circuits have been described at a relatively high-level, without detail, in order to avoid unnecessarily obscuring aspects of the present teachings.

[0025] The present disclosure generally relates to systems and methods for managing memory tables in a processing system. Processor cores are currently being developed that can support different operating environments and virtual machines. For example, one part of a computing system may implement a radix mode of translation, which uses a series of nested tables instead of a single large hashed table to find page table entries for its particular operating system (OS), while another part of the system implements a PowerPC, which uses a different translation mode for its corresponding OS. For example, a hypervisor, sometimes referred to as a virtual machine monitor (VMM), may create and run virtual machines (VMs) by isolating the hypervisor operating system and resources from the virtual machines, enabling the creation and management of such machines, which may be based on different OSs while sharing the same hardware. Each operating system may involve different address translations based on different page tables. When a process requests access to data in its memory, the OS's role is to map the virtual address (VA) provided by the process to the physical address of the actual memory where the data is stored. The page table is where the operating system stores its mappings from virtual addresses to physical addresses, and each mapping is also known as a page table entry (PTE). Because different operating systems are used, there may be different translation units, sometimes referred to herein as translation modes.

[0026] PTEs are typically used to translate virtual addresses discovered by the operating system into physical addresses used by hardware that processes application program instructions. The hardware that performs such translation is sometimes referred to as a memory management unit (MMU). Each entry in a page table includes an indication of whether the corresponding page is in physical memory. If it is in physical memory, the page table entry includes the actual memory address where the page is stored. When the hardware references a page, if the page table entry for the page indicates that it is not currently in physical memory, the hardware raises a page fault exception and invokes the operating system's page supervisor component.

[0027] Currently, high-end computer systems may support multiple page sizes, which presents a problem when implementing performance-enhancing concurrent table walks. When a hardware design has multiple table walk engines, a new translation request checks the currently active table walk engine for virtual address collisions. An address collision occurs when two VA's translations occur on the same page.

[0028] Typically, if a new VA translation request could potentially be on the same page as an active translation table walk, it is stalled to avoid multiple entries in the translation cache for the same page. Such stalls destroy the performance-enhancing benefits of multiple hardware table walk engines.

[0029] The teachings herein provide a sleep and / or wake-up interface and support hardware logic between a translation requester and multiple translation table walk (TW) engines to allow simultaneous table walk overlap. When a new translation request is received, the system uses the progress of the active table walk engine to determine the number of VA bits to compare. With multiple active TW engines, each engine generates its own range of VA bits based on its individual translation walk progress. The result of the comparison determines whether the new translation should be "put to sleep." The new translation receives a "wake-up" when the active TW engine advances to the next translation level, allowing simultaneous overlap.

[0030] In one aspect of the present disclosure, the new request is only temporarily "put to sleep" until the active TW engine can guarantee that the new request does not share the same page. At this point, the active table walk "wakes up" the new request, thereby allowing it to not only operate in parallel but also utilize the current (i.e., active) translation walk progress. For example, the new request may utilize the active translation walk progress if the active walk has stored intermediate results in the translation cache. In some scenarios, a separate page walk cache (PWC) is used for these intermediate results.

[0031] In embodiments where multiple page sizes are supported, the address collision logic compares the most significant bits (MSBs) of the addresses up to the bit boundary of the largest supported page size. Without the teachings herein, new requests would be stalled until the active translation causing the address collision was resolved, thereby substantially slowing down the computing system.

[0032] Accordingly, the teachings herein provide a computer system and method for a processor that supports multiple page sizes and simultaneous table walks. The techniques described herein may be implemented in many ways. An exemplary implementation is shown below with reference to the following figures. [Example Architecture]

[0033] Reference is now made to Figure 1, which is a conceptual block diagram of a memory address translation system 100, sometimes referred to as a memory management unit (MMU), that supports multiple parallel table walks, consistent with an illustrative embodiment. System 100 includes a translation requester 102 configured to provide requests for RAs based on VAs. For example, the translation requests may be hashed page table (HPT) translation requests, segment table translation requests, non-nested radix requests, nested radix requests, etc.

[0034] A translation cache-translation lookaside buffer (TLB) interface 110 is present, which is configured to receive cache requests from translation requester module 102 and, depending on whether there is an address "miss" 126 in the TLB, provide the request to one or more table walk (TW) machines 130-136 and sleep and wake control module 120. A TLB is a memory cache operable to reduce the time it takes to access user memory locations. TLB 110 stores previous successful translation results. For example, TLB 110 may contain previous translations of different types, such as EA to VA, VA to RA, and EA to RA. If a previous successful translation request for a similar request is found by TLB 110 (i.e., a TLB "hit"), the request is returned to the translation requester with the physical RA. However, if a new translation request 104 from the translation requester module 102 misses the TLB 110 (i.e., no previously successful translation request is identified for the current address, hence a TLB miss), the new request VA 104 is forwarded to the sleep and wake and control module 120.

[0035] The sleep and wake control module 120 compares the received virtual address with the virtual addresses that currently have an active table walk (e.g., 130 to 136). The address range is configured by the state of the table walk. As used herein, the state of the table walk refers to the level of the radix tree at which the active table walk is currently operating. For example, if the active walk is operating at level 2, then the address range compared is 12:33, if at level 3 it is 12:42, and so on.

[0036] Upon determining that an address match exists in the currently active table walk, the new translation request is returned 106 to the sleep request translation requester module 102 (e.g., "put-to-sleep" for the active TW (Req_ID)). In response, the translation requester module 102 stores the new translation request as a sleep request (e.g., 103) with a corresponding request identification (ID) number. However, if an address match does not exist, the new translation request is assigned 122 to a TW machine (e.g., 130 through 136). In one embodiment, there is a direct path from the translation cache 110 to the table walk machines 130 through 136. This path 124 is configured to directly provide VAs to the table walk machines 130 through 136. If intermediate results from the active TW are stored in the translation cache 110, path 124 may also provide them to the new translation request.

[0037] The active table walk machine completes the corresponding radix conversion level (e.g., L1, L2, L3, L4, etc.) and sends a “wake-up” signal 140 with its corresponding ID to the conversion requester module 102, which triggers the conversion requester module 102 to resend the currently sleeping conversion request based on the received ID. When a new conversion request is “put to sleep,” it is the active TW ID with which the address collision is associated. Accordingly, when an active TW completes a radix level, it sends its ID 140 to the conversion requester 102, which in turn wakes up any sleeping “new” requests 103 with the same ID. In one embodiment, more than one sleep request can be activated (i.e., woken up) by a single ID.

[0038] Reference is now made to Figure 2, which is a conceptual process flow diagram for memory address translation in a multiple page size environment, consistent with an exemplary embodiment. By way of example only and not limitation, consider two base conversion requests for a 64-bit VA', where the possible supported page sizes are 1G, 2M, and 4K. Without the teachings herein, any conversion request in the same 1G address range, VA(0:33), would be considered. <big endian>will be stalled if there is one active table walk within its range, regardless of the actual (unknown) page size. If the actual page size is 4k, then (250,000-1) other possible 4k page translations will suddenly be stalled, thereby preventing any table walk overlaps.

[0039] Reference is now made to Figures 3A and 3B, which provide an exemplary sleep / wake parallel table walk consistent with an exemplary embodiment. For example, during a radix conversion walk, a set of conversion tables is accessed at each conversion walk level. The VAs are partitioned into separate address bit groups, where each group is used to index into a conversion table at a given conversion level (e.g., L1 through L4 in Figure 3A). A translation table entry contains the base address of the translation table at the next conversion walk level, which is then indexed by the next VA bit group.

[0040] FIG. 3B is a table of two virtual address translation requests processed by a system consistent with an exemplary embodiment. VA′ represents a first (e.g., existing) translation request currently being processed by a table walk engine, while VA″ represents a second (i.e., new) translation request received after the first translation request. As shown in the example of FIG. 3B, at level 1 (i.e., (12:24)), the address is the same (i.e., X017), thereby potentially leading to a translation collision. In this regard, VA″ is put to sleep until the level 1 active table walk for VA′ is completed. Similarly, at level 2 (i.e., (25:33)), the address is the same (i.e., X29). Consequently, VA″ is stalled (e.g., put to sleep) until this level 2 is completed for VA′ by the corresponding table walk engine.

[0041] In contrast, for level 3, the comparison between VA' and VA'' indicates that the addresses for that translation level are different (i.e., X1E vs. X07), thereby allowing VA' and VA'' to be processed simultaneously (e.g., in parallel) by the same table walk engine. Accordingly, even in the case of different page sizes, the teachings herein facilitate efficient processing of address translation requests that maximizes processing parallelism, thereby significantly enhancing memory address translation throughput.

[0042] Returning to Figure 2, for example, consider the radix table walk of VA(12:63) 202. Since the smallest page size is 4k (see L4 in Figure 3A), VA(12:51) can be converted to Real(Address) Page Number, RPN(12:51).

[0043] The level 1 Radix Tree Directory Base (RTDB) is the base address of the first radix translation table provided to the RA and the system. VA(12:24) 204 is used to index into this translation table, and the accessed entry contains the level 2 RTDB. VA(25:33) 206 indexes the level 2 table to find the level 3 RTDB. VA(34:42) 208 indexes the level 3 table to find the level 4 RTDB. Finally, VA(43:51) 210 indexes the level 4 table to find the page table entry (PTE), which defines the translation from VA(12:51) to RPN(12:51).

[0044] In one embodiment, the active walk stores intermediate results in a translation cache. A separate page walk cache (PWC) can be used for intermediate results. For example, 206 refers to the RTDB discovered by the active walk. When cached, it can be used by new "launched" translation requests, thereby taking advantage of the current active table walk status.

[0045] Note that the RTDB as the base address of the translation table is provided as an example and not as a limitation. Other pointers may be used. For example, in one embodiment, the level 2 table entries may be PTEs instead of RTDBs. In this embodiment, the page size may be 1G. Similarly, the level 3 table entries may be PTEs, in which case the page size is 2M, as shown in the table of FIG. 3A.

[0046] In one embodiment, at each level of the tree, the mapping from VA to RTDB is stored in a page walk cache (PWC) to accelerate subsequent table walks. For example, the PWC entry for VA(12:42) provides the RTDB for level 4.

[0047] When a new translation request is received by a group of table walk (TW) engines, the system performs an address collision comparison with the active TW engine. If the VA(12:33) of the active TW engine (1G boundary) matches the new request and the TW engine has not yet accessed an L2 translation table entry, then the new request will temporarily "sleep" until the active TW engine determines that a 1G PTE (L2) does not exist. In other words, the new request will temporarily "sleep" until the active TW engine accesses a level 2 table entry, and if not, proceed to level 3 operation. Since the largest page size supported in this example is 1G, it corresponds to level 2 of the radix tree, which in turn corresponds to (12:33).

[0048] In this scenario, the translation requester stalls its request until the active TW engine sends a wake-up signal, which it sends after accessing the L2 table entry and begins accessing the L3 entry.

[0049] At this point, a new translation request is again sent to the group of one or more TW engines and VA(12:33) is again compared, but this time the active TW engine has progressed beyond the L2 translation table, so this comparison does not generate a sleep signal.

[0050] However, if the active TW engine has not yet accessed the L3 translation table, then the VA comparison is extended to VA(12:42). In the case of a VA comparison miss, the new request is assigned to an idle (e.g., available) TW engine, and the two translation walks can operate in parallel without attenuation.

[0051] When a new translation request is received, the system uses the progress state (i.e., translation level) of the active TW entry to determine the number of VA bits to compare. Note that with multiple active TW engines, each engine generates its own range of VA bits based on its individual translation walk progress.

[0052] In one embodiment, in addition to running the transform walks in parallel, when an active TW engine sends a "wakeup" signal, it also writes a PWC in VA(12:33) containing the level 3 RTDB, which is immediately available for new requests. Although not explicitly described, the teachings herein also support a "sleep / wakeup" flow when there is a collision in VA(12:42) with an active TW engine that has not yet accessed the L3 RTDB (2M boundary / potential PTE) as well as higher levels. [Example Process]

[0053] With the foregoing overview of the exemplary systems 100 and 200, it may now be helpful to consider a high-level description of an exemplary process. To that end, FIG. 4 presents an exemplary process 400 for translating memory addresses while supporting parallel table walks, consistent with an exemplary embodiment. Process 400 is illustrated as a collection of blocks in a logical flowchart, which represent a sequence of operations that may be implemented in hardware, software, or a combination thereof. In the context of software, the blocks represent computer-executable instructions that, when executed by one or more processors, perform the described operations. Generally, computer-executable instructions may include routines, programs, objects, components, data, structures, and the like that perform a function or implement an abstract data type. Within each process, the order in which operations are described is not intended to be construed as a limitation, and any number of the described blocks may be combined in any order, executed in parallel, or a combination thereof, to implement the process. For purposes of explanation, process 400 is described with reference to the architecture of FIG. 1.

[0054] In block 402, the translation cache 110 receives a request to translate a virtual address (VA) to a real address (RA) in physical memory.

[0055] In block 404, translation cache 110 compares the received VA with the VA's of all currently active table walks in the group of table walk machines 130-136.

[0056] Upon determining based on the comparison that there is no address match at a given table walk machine in the group of table walk machines (i.e., "No" in decision block 406), the request is forwarded to block 414 where a table walk machine (e.g., 130 of the group of table walk machines 130-136) processes the translation request.

[0057] However, upon determining that an address match exists at a given table walk machine of the group of table walk machines (i.e., "yes" at decision block 406), the process continues at block 408, where the translation request, along with an identification number (ID), is returned to the translation requester module to be put to sleep. In other words, the translation request is temporarily stalled.

[0058] At block 410, it is determined whether a given table walk machine has completed its translation level. If so (i.e., "yes" at decision block 410), the process continues at block 412, where a wake-up signal having ID 140 is sent to translation requester module 102, triggering the wake-up and processing 414 of a put to sleep translation request (e.g., 103). In one embodiment, when a "put to sleep" request receives a wake-up signal, the process continues at block 404, where translation cache 110 compares the received VA with the VA' of all currently active table walks in group 130-136 of table walk machines. Because the active TW has completed a level, the next address comparison includes more bits. In this manner, the table walk of the VA of the translation request with ID is facilitated in parallel with one or more other table walks of other translation requests in group 130-136 of table walk machines. [Example of computer platform]

[0059] In one embodiment, the functions associated with providing a memory address translation system that facilitates maximum parallelism may be performed in conjunction with the use of one or more computing devices. Figure 5 provides a functional block diagram illustration of a computer hardware platform 500 that may be used to host a memory address translation unit 540.

[0060] The computer platform 500 may include a central processing unit (CPU) 504, a hard disk drive (HDD) 506, a random access memory (RAM) and / or read-only memory (ROM) 508, a keyboard 510, a mouse 512, a display 514, and a communication interface 516 connected to a system bus 502.

[0061] In one embodiment, HDD 506 has the capability to include storage of programs that may execute various processes, such as memory address translation unit 540, in the manner described herein. Memory address translation unit 540 may have various modules configured to perform different functions, such as those described in the context of FIGS. 1 and 2. For example, there may be a translation requester operable to provide VA to RA translation requests. There may be a sleep and wake control module 544 operable to determine the status of a currently active table walk machine and control the sleep and wake status of the request accordingly. There may be a translation cache configured to receive cache requests from translation requester module 542 and provide them to one or more table walk (TW) machines (e.g., 548 through 552) or sleep and wake control module 546 depending on whether there is an address "hit" or an address "miss." These modules may perform all of the functions described herein and more.

[0062] Although modules 542 through 552 are shown in FIG. 5 as part of HDD 506, in some embodiments, one or more of these modules may be implemented in hardware in computing device 500. For example, the modules described herein may be implemented partially in hardware and partially in software. That is, one or more of the components of memory address translation unit 540 shown in FIG. 5 may be implemented in the form of an electronic circuit having transistors, diodes, capacitors, resistors, inductors, varactors, and / or memristors. In other words, memory address translation unit 540 may be implemented by components of the CPU and / or modules of RAM / ROM 508 with one or more specially designed electronic circuits that perform the specific tasks and functions described herein. [Cloud platform example]

[0063] As discussed above, functionality related to providing a unified memory address translation system may include distributed computing and / or storage architectures, such as cloud. While this disclosure includes detailed descriptions related to cloud computing, it should be understood that implementation of the teachings described herein is not limited to cloud computing environments. Rather, embodiments of the present disclosure may be implemented in conjunction with any other type of computing environment now known or later developed.

[0064] Cloud computing is a service delivery model for enabling convenient, on-demand network access to a shared pool of configurable computing resources (e.g., networks, network bandwidth, servers, processing, memory, storage, applications, virtual machines, and services) that can be rapidly provisioned and released with minimal administrative effort or interaction with a service provider. This cloud model may include at least five characteristics, at least three service models, and at least four deployment models.

[0065] The characteristics are as follows:

[0066] On-Demand Self-Service: Cloud consumers can unilaterally provision computing capacity, such as server time and network storage, automatically as needed, without requiring human interaction with the service provider.

[0067] Wide network access: This capability is available over the network and accessed through standard mechanisms that facilitate use by heterogeneous thin or thick client platforms (eg, cell phones, laptops, and PDAs).

[0068] Resource Pooling: A provider's computing resources are pooled to serve multiple consumers using a multi-tenant model, with different physical and virtual resources dynamically allocated and reallocated according to demand. Consumers generally have no control or knowledge over the exact location of the provided resources, although there is a type of location independence in that they may be able to specify location at a higher level of abstraction (e.g., country, state, or data center).

[0069] Rapid Elasticity: This capacity can be rapidly and elastically provisioned, in some cases automatically, to rapidly scale out, and rapidly released to rapidly scale in. To the consumer, the capacity available for provisioning often appears unlimited and can be purchased in any quantity at any point in time.

[0070] Measured Services: Cloud systems automatically control and optimize resource usage by leveraging metering capabilities at a level of abstraction appropriate to the type of service (e.g., storage, processing, bandwidth, and active user accounts). Resource utilization can be monitored, controlled, and reported, providing transparency to both providers and consumers of the services used.

[0071] The service model is as follows:

[0072] Software as a Service (SaaS): The consumer is offered the ability to use a provider's applications running on a cloud infrastructure. The applications are accessible from a variety of client devices through a thin-client interface such as a web browser (e.g., web-based email). The consumer does not manage or control the underlying cloud infrastructure, including the network, servers, operating systems, storage, or even individual application capabilities, with the possible exception of limited user-specific application configuration settings.

[0073] Platform as a Service (PaaS): The ability offered to consumers is to deploy applications they create or acquire, written using programming languages ​​and tools supported by the provider, on a cloud infrastructure. The consumer does not manage or control the underlying cloud infrastructure, including the network, servers, operating systems, or storage, but does have control over the deployed applications and, in some cases, the application hosting environment configuration.

[0074] Infrastructure as a Service (IaaS): The ability offered to consumers is to provision processing, storage, network, and other basic computing resources onto which they can deploy and run any software, which may include operating systems and applications. The consumer does not manage or control the underlying cloud infrastructure, but does have control over the operating systems, storage, deployed applications, and in some cases, limited control over selected networking components (e.g., host firewalls).

[0075] The deployment model is as follows:

[0076] Private Cloud: This cloud infrastructure operates solely for an organization. It may be managed by that organization or a third party and may exist on-premise or off-premise.

[0077] Community Cloud: This cloud infrastructure is shared by several organizations and supports a specific community with shared concerns (e.g., mission, security requirements, policy and compliance considerations). It may be managed by the organizations or a third party and may exist on-premises or off-premises.

[0078] Public Cloud: This cloud infrastructure is made available to the general public or large industry groups and is owned by an organization that sells cloud services.

[0079] Hybrid Cloud: This cloud infrastructure is a composite of two or more clouds (private, community, or public) that remain distinct entities but are bound together by standard or proprietary technologies that allow for data and application portability (e.g., cloud bursting for load balancing between clouds).

[0080] Cloud computing environments are service-oriented with a focus on statelessness, low coupling, modularity, and semantic interoperability. At the core of cloud computing is an infrastructure that includes a network of interconnected nodes.

[0081] Referring now to FIG. 6 , an exemplary cloud computing environment 600 is shown. As shown, the cloud computing environment 600 includes one or more cloud computing nodes 610 with which local computing devices used by cloud consumers, such as, for example, a personal digital assistant (PDA) or mobile phone 654A, a desktop computer 654B, a laptop computer 654C, or an automobile computer system 654N, or combinations thereof, can communicate. The nodes 610 may communicate with each other. They may be physically or virtually grouped (not shown) in one or more networks, such as a private cloud, a community cloud, a public cloud, or a hybrid cloud, or combinations thereof, as described above. This enables the cloud computing environment 650 to provide infrastructure, platform, and / or software as a service without the cloud consumer having to maintain resources on their local computing device. It will be understood that the types of computing devices 654A-N shown in FIG. 6 are intended to be illustrative only, and that computing node 610 and cloud computing environment 650 may communicate with any type of computerized device via any type of network and / or network-addressable connection (e.g., using a web browser).

[0082] Referring now to Figure 7, a set of functional abstraction layers provided by cloud computing environment 650 (Figure 6) is shown. It should be understood in advance that the components, layers, and functions shown in Figure 7 are intended to be illustrative only, and embodiments of the present disclosure are not limited thereto. As shown, the following layers and corresponding functions are provided:

[0083] Hardware and software layer 760 includes hardware and software components. Examples of hardware components include mainframe 761, reduced instruction set computer (RISC) architecture-based server 762, server 763, blade server 764, storage device 765, and network and network components 766. In some embodiments, software components include network application server software 767 and database software 768.

[0084] The virtualization layer 770 provides an abstraction layer from which the following examples of virtual entities may be provided: virtual servers 771, virtual storage 772, virtual networks including virtual private networks 773, virtual applications and operating systems 774, and virtual clients 775.

[0085] In one example, management layer 780 can provide the following functions: Resource provisioning 781 provides for dynamic procurement of computing resources and other resources utilized to perform tasks within the cloud computing environment. Metering and pricing 782 provides cost tracking as resources are utilized within the cloud computing environment and billing or invoicing for the consumption of these resources. In one example, these resources may include application software licenses. Security provides identity verification of cloud consumers and tasks, as well as protection of data and other resources. User portal 783 provides access to the cloud computing environment for consumers and system administrators. Service level management 784 provides cloud computing resource allocation and management so that required service levels are met. Service level agreement (SLA) planning and fulfillment 785 provides for proactive provisioning and procurement of cloud computing resources to anticipate future requirements according to SLAs.

[0086] Workload tier 790 provides examples of functions for which a cloud computing environment may be utilized. Examples of workloads and functions that may be provided from this tier include mapping and navigation 791; software development and lifecycle management 792; virtual classroom instruction delivery 793; data analytics processing 794; transaction processing 795; and transformation engine 796, as described herein. [Conclusion]

[0087] The description of various embodiments of the present teachings has been presented for illustrative purposes, but is not intended to be exhaustive or limited to the disclosed embodiments. Many modifications and variations will be apparent to those skilled in the art without departing from the scope and spirit of the described embodiments. The terms used herein have been selected to best explain the principles of the embodiments, practical applications, or technical improvements beyond those found in the market, or to enable others skilled in the art to understand the embodiments disclosed herein.

[0088] While the above describes what is believed to be the best mode and / or alternative examples, it is understood that various modifications can be made therein, that the subject matter disclosed herein can be implemented in various forms and examples, and that the teachings can be applied to many applications, only some of which are described herein. It is intended that the following claims claim all such applications, modifications, and variations as fall within the true scope of the present teachings.

[0089] The components, steps, features, objects, benefits, and advantages described herein are merely exemplary. Neither they nor the descriptions associated therewith are intended to limit the scope of protection. While various advantages have been described herein, it will be understood that not all embodiments necessarily include all advantages. Unless otherwise expressly stated, all measurements, values, ratings, positions, dimensions, sizes, and other specifications described herein, including the following claims, are approximate and not exact. They are intended to have a reasonable range consistent with the functions to which they relate and that which is customary in the technical field to which they pertain.

[0090] Many other embodiments are also contemplated, including those having fewer, additional, or different or combinations of components, steps, features, objects, benefits, and advantages, including those in which the components and / or steps are configured and / or ordered separately.

[0091] Aspects of the present disclosure are described herein with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the present disclosure, or combinations thereof. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer-readable program instructions.

[0092] These computer-readable program instructions may be provided to a processor of a suitably configured computer, special purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions, executed by the processor of the computer or other programmable data processing apparatus, create means for implementing the functions / acts specified in one or more blocks of the flowcharts or block diagrams, or combinations thereof. These computer-readable program instructions may also be stored on a computer-readable storage medium that can instruct a computer, programmable data processing apparatus, or other device, or combinations thereof, to function in a particular manner. A computer-readable storage medium having instructions stored thereon thereby includes an article of manufacture including instructions that implement aspects of the functions / acts specified in one or more blocks of the flowcharts or block diagrams, or combinations thereof.

[0093] The computer-readable program instructions may also be loaded into a computer, other programmable data processing apparatus, or other device and cause the computer, other programmable apparatus, or other device to perform a series of operational steps to generate a computer-implemented process, such that the instructions executing on the computer, other programmable apparatus, or other device implement the function(s) / act(s) specified in one or more blocks of the flowcharts and / or block diagrams.

[0094] The call flows, flowcharts, and block diagrams in the figures herein illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of the present disclosure. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of instructions, including one or more executable instructions for implementing a specified logical function. In some alternative implementations, the functions noted in the blocks may occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may be executed in the reverse order, depending on the functionality involved. It should also be noted that each block in the block diagrams and / or flowchart diagrams, and combinations of blocks in the block diagrams and / or flowchart diagrams, may be implemented by a special-purpose hardware-based system that performs the specified functions or operations or executes a combination of special-purpose hardware and computer instructions.

[0095] While the foregoing has been described in conjunction with exemplary embodiments, it is understood that the term "exemplary" is intended to mean merely an example, not best or optimal. Except as noted immediately above, nothing described or illustrated is intended to, and should be construed as, providing the public with any component, step, feature, object, benefit, advantage, or equivalent, whether claimed or not.

[0096] It will be understood that the terms and expressions used herein have the ordinary meanings ascribed to such terms and expressions with respect to their respective fields of inquiry and study, unless a specific meaning is otherwise stated herein. Relative terms such as first and second may be used solely to distinguish one entity or action from another, without necessarily requiring or implying any actual relationship or order between such entities or actions. The terms "comprises," "comprising," or any other variations thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that includes a list of elements does not include only those elements, but may also include other elements not inherent in or expressly listed in such process, method, article, or apparatus. An element preceded by "a" or "an" does not, in the absence of further constraints, exclude the presence of additional identical elements in the process, method, article, or apparatus that includes that element.

[0097] An Abstract of the Disclosure is provided to allow the reader to quickly ascertain the nature of the technical disclosure. It is submitted with the understanding that it will not be used to interpret or limit the scope or meaning of the claims. It can also be seen that in the foregoing Detailed Description, various features are grouped together in various embodiments for the purpose of streamlining the disclosure. This method of disclosure is not to be interpreted as reflecting an intention that the claimed embodiments have more features than are expressly recited in each claim. Rather, as the following claims reflect, inventive subject matter lies in less than all features of a single disclosed embodiment. Accordingly, the following claims are hereby incorporated into the Detailed Description, with each claim standing on its own as separately claimed subject matter.< / big>

Claims

1. receiving a request for translation from a virtual address (VA) to a real address (RA) in physical memory; comparing the received VA with the VA' of all currently active table walks in the group of table walk machines; and upon determining based on the comparison that an address match exists within a given table walk machine of the group of table walk machines, sending the translation request along with an identification number (ID) to a translation requester module for placing into a sleep state; upon determining that the given table walk machine has completed its translation level, sending a wake-up signal having the ID to the translation requester module to trigger the wake-up and processing of the put-to-sleep translation request; and providing a table walk of the VA for the translation request having the ID in parallel with one or more other table walks of other translation requests of the group of table walk machines; 1. A method for providing memory address translation in a multiple page size environment, comprising:

2. 2. The method of claim 1, wherein the step of comparing the received VA with the VA' of the currently active table walk comprises, for each currently active table walk: comparing virtual address bits of the received VA with a range of addresses at the translation level of the currently active table walk.

3. 2. The method of claim 1, further comprising: for each active table walk, using a translation level of the table walk to determine a number of address bits to compare to determine if an address collision exists.

4. 2. The method of claim 1, wherein the step of comparing the received VA with the VA' of the currently active table walk comprises, for each currently active table walk, comparing a most significant bit (MSB) of the address up to a bit boundary of the largest supported page size.

5. 2. The method of claim 1, further comprising, upon determining based on the comparison that no address match exists within a given table walk machine of the group of table walk machines, sending the translation request to be processed directly by a table walk machine of the group of table walk machines.

6. determining, upon receiving the translation request, by a translation cache module, whether the translation request for the VA has previously been successfully processed; and sending the conversion request directly to one or more table walk machines upon determining that the conversion request of the VA has not previously been successfully processed. The method of claim 1 further comprising:

7. The conversion request is Hashed Page Table (HPT) requests; Segment table request; A non-nested cardinality request; or Nested Cardinality Requests The method of claim 1 , comprising at least one of:

8. 2. The method of claim 1, wherein the completed translation level is a level 1 radix tree directory base (RTDB), which is used as a base address for a first radix translation table.

9. 2. The method of claim 1, wherein the given table walk machine at the next level is a page table entry (PTE), which is used to define a next range of translations.

10. 1. A memory address translation system, comprising: a translation requester module configured to provide a translation request from a virtual address (VA) to a real address (RA) in physical memory; a translation cache module coupled to the translation requester module and configured to receive the translation request from the translation requester module; a group of table walk machines coupled to the translation cache module and the translation requester module and configured to perform table walks; and a sleep and wake control module coupled to the group of the translation requester module, the translation cache module, and the table walk machine; the sleep and wake control module comprising: comparing the received VA with the VA' of all currently active table walks in the group of table walk machines; and sending the translation request along with an identification number (ID) to the translation requester module for putting to sleep upon determining based on the comparison that an address match exists within a given table walk machine of the group of table walk machines; configured to: wherein each table walk machine is configured to provide a wake-up signal having an identification number (ID) to the translation requester module upon completion of its translation level, thereby triggering the wake-up and processing of currently sleeping translation requests having the corresponding ID, and providing parallel translation table walks within the group of table walk machines. system.

11. The system of claim 10 , wherein the system supports multiple page sizes.

12. 11. The system of claim 10, wherein the comparing the received VA with the VA' of the currently active table walk includes, for each currently active table walk, comparing virtual address bits of the received VA with a range of addresses at a translation level of the currently active table walk.

13. 11. The system of claim 10, wherein the sleep and wake control module is configured to, for each active table walk, use a translation level of the table walk to determine a number of address bits to compare to determine whether an address collision exists.

14. 11. The system of claim 10, wherein the comparison by the sleep and wake control module of the received VA with the VA' of the currently active table walk includes, for each currently active table walk, comparing a most significant bit (MSB) of the address up to a bit boundary of the largest supported page size.

15. 11. The system of claim 10, further comprising, upon determining based on the comparison that no address match exists within a given table walk machine of the group of table walk machines, sending the translation request to be processed directly by the given table walk machine of the group of table walk machines.

16. The conversion cache module: Upon receiving the conversion request, determining whether the conversion request of the VA has previously been successfully processed; and sending the conversion request directly to one or more table walk machines upon determining that the conversion request of the VA has not previously been successfully processed. The system of claim 10 , further configured to:

17. The transformation requester module receives the following transformation requests: Hashed Page Table (HPT) requests; Segment table request; A non-nested cardinality request; or Nested Cardinality Requests The system of claim 10 configured to provide at least one of:

18. The completed translation level is a level 1 radix tree directory base (RTDB), which is used as the base address of the first radix translation table; and 11. The system of claim 10, wherein the sleep and wake control module is configured to use the level 1 RTDB as a base address for a first radix conversion table.

19. processor; physical memory coupled to said processor; coupled to the processor; and receiving a request to translate a virtual address (VA) to a real address (RA) of said physical memory; comparing the received VA with the VA' of all currently active table walks in the group of table walk machines; and upon determining based on the comparison that an address match exists within a given table walk machine of the group of table walk machines, sending the translation request along with an identification number (ID) to a translation requester module for placing into a sleep state; Upon determining that the given table walk machine has completed its translation level, sending a wake-up signal having the ID to the translation requester module to trigger the wake-up and processing of the put-to-sleep translation request; and providing a table walk of the VA for the translation request having the ID in parallel with one or more other table walks for other translation requests in the group of table walk machines; a memory address translation system configured to: A computing device comprising:

20. 20. The computing device of claim 19, wherein the memory address translation system supports multiple page sizes.

21. A computer program product for causing an information processing system to carry out the method according to any one of claims 1 to 9.

Images