Patent Description:
Computer processor technology is rapidly advancing, resulting in continually increasing processor performance, which relies in part on the available memory within the system (e.g. memory available to central processing units (CPUs) in a server). The performance of such processors can be adversely affected by other bottlenecks in the computer. For example, the speed of data transfer from hard disk drives into random access memory (RAM) is a bottleneck in computer performance. One way to reduce the impact of bottlenecks in the computer (e.g., server) is to store more data in RAM. However, the cost of RAM remains high enough that it is typically cost prohibitive to use very large amounts of RAM in computers, such as would be needed in server applications.

For example, presently up to about half the capital expenditure (CAPEX) cost for a server is dynamic RAM (DRAM). As such, a significant increase in the amount of DRAM in the server would result in a significant increase in the CAPEX cost of the server. As a result, presently available techniques for scaling for DRAM, particularly in server applications, add significant cost to the overall system. That is, as memory requirements increase, the need for physical memory (such as DRAM) increases, and with conventional techniques, the only practical approach to maintain system performance is to add more memory. Memory compression techniques are also known, but these techniques typically adversely affect system performance.

Thus, present memory management techniques include (i) compression techniques that involve compression on the storage device (e.g., storage disk), which adversely affects system performance, including system speed, or (ii) increasing the amount of physical memory, such as DRAM, which increases overall system cost. As a result, present techniques are not effectively scalable without a loss in system performance or increase in system cost.

<CIT> relates to methods and apparatus for scalable application-customized memory compression. Data is selectively stored in system memory using compressed formats or uncompressed format using a plurality of compression schemes. A compression ID is used to identify the compression scheme (or no compression) to be used and included with read and write requests submitted to a memory controller. For memory writes, the memory controller dynamically compresses data written to memory cache lines using compression algorithms (or no compression) identified by compression ID. For memory reads, the memory controller dynamically decompresses data stored memory cache lines in compressed formats using decompression algorithms identified by the compression ID. Page tables and TLB entries are augments to include a compression ID field. The format of memory cache lines includes a compression metabit indicating whether the data in the cache line is compressed. Support for DMA reads and writes from IO devices such as GPUs using selective memory compression is also provided.

<CIT> relates to dynamic memory expansion that is based on data compression. Data represented in at least one page to be written to a main memory of a computing device is received. The data is compressed in the at least one page to generate at least one compressed physical page and a metadata entry corresponding to each page of the at least one compressed physical page. The metadata entry is cached in a metadata cache including metadata entries and pointers to the uncompressed region of the at least one compressed physical page.

It is the object of the present invention to provide an improved memory management system.

A computerized method for tracking compressed memory comprises accessing a sector translation table (STT) defined by a descriptor, wherein the descriptor includes a cache line map and a plurality of sector pointers pointing to sector memory. The computerized method further comprises obtaining from the cache line map, cache line metadata relating to a cache line, wherein the cache line metadata includes one or more flags, a sector number, a cache segment length, and a length of the cache line. The computerized method also includes loading the cache line from physical memory into a last level cache (LLC) based on the cache line metadata, wherein a size of a compression block is the same as a size of a single cache line. The computerized method additionally includes tracking compressed physical memory using a plurality of cache lines.

In the figures, the systems are illustrated as schematic drawings. The drawings may not be to scale.

The computing devices and methods described herein are configured to perform inline physical memory compression using a combination of physical memory compression techniques and cache memory compression techniques in some examples. Inline physical memory compression implements real time and transparent memory compression inside a memory controller. As a result, reduced physical memory can be used, such as in a server, with the same amount processing being performed (e.g., a reduction of physical memory by a factor of two on average to perform the same level of processing).

In various examples, a memory management architecture and/or system performs memory compression at the cache line size. That is, memory management techniques disclosed herein provide inline memory compression at the cache line boundary. In one particular example, a cache compression algorithm is used to compress DRAM, such that cache compression techniques are extended to physical memory with memory management. A cache line map is implemented in some examples to track the memory compression at the cache line size. That is, the present disclosure uses a compression block size that is a single cache line size and not multiple cache lines. As a result, there is no discrepancy between the CPU cache line size and compression block size, such that the addition of compression cache is not needed, which would increase the performance overhead and bandwidth overhead. Thus, the compression algorithm of the present disclosure is "lightweight" and power efficient (e.g., not "heavy duty" or expensive in terms of surface area, power, and latency). In this manner, when a processor is programmed to perform the operations described herein, the processor is used in an unconventional way, and allows for increased memory performance without the addition of physical memory or decreased processor performance, which thereby improves the user experience.

In some examples, the memory management techniques perform compression higher in the overall compression hierarchy. That is, cache lines are stored compressed in Last Level Cache (LLC), resulting in an increased LLC and increased performance. With the present disclosure, and the cache compression algorithm described herein, compression of physical memory is performed using memory management techniques that contribute a very small (e.g., <NUM>%) overhead to manage compressed physical memory.

More particularly, various examples perform physical memory compression that includes compression of user data, as well as compression of memory blocks not otherwise used. For example, most applications tend to have zero blocks in memory, which can account for as much as twenty-one percent of the total physical memory blocks in server workloads. These blocks are rarely accessed by the CPU and tend to be very "cold". The inline physical memory compression disclosed herein compresses these blocks efficiently, thereby freeing most of these memory blocks (e.g., pages) to be used elsewhere.

In one example, total physical memory compression is implemented, which decreases system cost (reduces the demand for physical memory) and improves overall system performance (reduces I/O and paging operations). Two configurations are disclosed herein to implement physical memory compression: CPU based and external memory management controller (MMC)/Bridge based. However, as should be appreciated, the present disclosure is not limited to these configurations, which are described for illustrative purposes only. Various systems implemented as different architectures will now be described.

<FIG> is a block diagram illustrating a memory management architecture <NUM> in accordance with one example. In this implementation, the memory management architecture <NUM> is illustrated as a CPU based memory compression configuration. That is, the memory management architecture <NUM> is a CPU based cache management configuration, wherein the compression is integrated in the CPU memory hierarchy and compression/decompression is seamlessly performed as part of the load/store operation semantics. There are two different arrangements for the CPU based memory compression configuration. In a first arrangement as illustrated in <FIG>, the compression/decompression occurs at the physical memory level. That is, compressors and decompressors <NUM> are positioned (connected) between an LLC <NUM>, illustrated as a level <NUM> shared cache (Shared Cache L3) and physical memory <NUM>, illustrated as DRAM. The compressors and decompressors <NUM> are used (invoked) as a result of LLC cache write backs or LLC read misses. As should be appreciated, in this configuration, the LLC <NUM> contains decompressed data, while the physical memory <NUM> is compressed. Additionally, the compressors and decompressors <NUM> can be any type of compression and decompression devices that perform data compression and decompression using one or more different signal processing techniques.

In a second arrangement as illustrated in <FIG>, the memory management architecture <NUM> is configured with compression/decompression, namely compressors and decompressors <NUM> that "sit on top" of the LLC <NUM> between the LLC <NUM> and the other caches <NUM>. That is, the compression and decompression operations happen after an LLC read or LLC write by the compressors and decompressors <NUM> connected between the LLC <NUM> and the other caches <NUM>. In this arrangement, both the LLC <NUM> and the physical memory <NUM> are compressed. Thus, in the memory management architecture of <FIG>, MMC based memory compression is provided with compressed L3 cache. It should be noted that like numerals represent like parts in the various examples.

As can be seen in <FIG> and <FIG>, in both arrangements, the MMC <NUM> and physical memory <NUM> operate at the physical addresses level and the LLC <NUM> operates at the real address level and communicates with other caches <NUM>, illustrated as level <NUM> and level <NUM> caches (Cache L1 and Cache L2). Additionally, a core <NUM> (e.g., a CPU processing core) operates at the virtual address level.

In operation, the MMC <NUM> controls memory management to provide physical memory compression as described in more detail herein. This control includes using a sector translation lookaside buffer (STLB) <NUM> and a free sector cache (FSC) <NUM> to manage the memory compression.

<FIG> is a block diagram illustrating a memory management architecture <NUM> in accordance with another example. In this implementation, the memory management architecture <NUM> is illustrated as a bridge based memory compression configuration, namely an external MMC/Bridge based configuration. In this configuration, compressors/decompressors <NUM> "sit outside" the CPU (and the integrated MMC <NUM> or <NUM>) in an external memory interface, illustrated as a compute express link (CXL) CPU-to-device interconnect configured as a CXL MMC <NUM> that is also coupled to external cache <NUM>. The compressors/decompressors <NUM> are external devices that thereby form part of an external memory controller or bridge. It should be appreciated that this configuration operates well in systems with extended memory systems through CXL, GenZ, OpenCAPI or other similar mechanisms. In various examples, the compression with the memory management architecture <NUM> facilitates reducing memory requirements, as well as reducing bandwidth requirements on the memory interconnect.

With the architectures described herein, the present disclosure implements one or more compression algorithms. In some examples, a cache compression algorithm is used to compress physical memory. Various compression algorithms and implementation considerations will now be discussed. In particular, in some examples, the compression algorithm is lossless, such that no information is lost in the process of compression. In other words, decompressing an already compressed block always generates the original uncompressed block <NUM>% of the time. Second, the compression algorithm of various examples has low latency for compression and decompression. Stated differently, decompression and compression does not increase memory load store latencies. Third, the compression algorithm provides a good compression efficiency for a cache line size (thirty-two or sixty-four bytes in various examples) memory block. It should be appreciated that compression algorithm complexity does not necessarily lead to a better compression ratio. Fourth, the compression algorithm has a low power consumption requirement, such that the overall thermal design power (TDP) of the CPU in not increased. Fifth, the compression algorithm has a low die area requirement.

The present disclosure recognizes the observation behind base-delta-immediate (BDI) compression that, for many cache lines, the data values stored within the line have a low dynamic range (i.e., the relative difference between values is small). In such cases, the cache line can be represented in a compact form using a common base value plus an array of relative differences ("deltas"), having a combined size that is much smaller than the original cache line.

Firewalls Policies Compression (FPC), a lossless, single pass, linear-time compression algorithm targets streams of double-precision floating-point data with unknown internal structure, such as the data seen by the network or a storage device in scientific and high-performance computing systems. FPC delivers a good average compression ratio on hard-to-compress numeric data.

C-Pack+Z achieves compression by two means: (<NUM>) using statically decided, compact encodings for frequently appearing data words and (<NUM>) encoding using a dynamically updated dictionary allowing adaptation to other frequently appearing words. The dictionary supports partial word matching as well as full word matching. Unlike BDI and FPC, the use of the dictionary, albeit small, can increase the compression ratio without adding extra complexity.

It was determined that C-Pack+Z has the highest compression ratio for block sizes of sixty-four bytes as illustrated in the graph <NUM> of <FIG>. GZIP is added as a comparison to the "gold standard" for offline data compression. However, GZIP requires large block sizes to attain optimum efficiency. For block size of sixty-four bytes, C-Pack+Z has superior performance and used in various examples.

An example of memory management of compressed memory will now be discussed. It should be appreciated that the memory management can be implemented with any of the architectures described herein, or other architectures.

More particularly, and with reference also to <FIG>, during operation, with a physical memory management <NUM> as illustrated in <FIG>, one or more processing cores execute instructions using virtual addresses. All virtual addresses are then converted to real addresses using a CPU TLB table (e.g., a STLB <NUM> table). The real addresses are used to access cache lines in the L1, L2, and L3 caches <NUM>, <NUM>, and <NUM>, respectively. In the case of an L3 cache miss, the real address is converted to a physical address before the MMC <NUM>, <NUM> or <NUM> issues a load or store operation to the DIMM. The MMC <NUM>, <NUM> or <NUM> performs this conversion using the STLB <NUM> inside the MMC <NUM>, <NUM> or <NUM>. In one example, the STLB <NUM> is a cache of entries from a sector translation table (STT) <NUM> as illustrated in <FIG>. The present disclosure implements physical memory organization as described below.

Physical memory is portioned into two main regions: a STT <NUM> region and a sector memory region <NUM>. The STT <NUM> is an array of a <NUM>-byte descriptor <NUM>. Each descriptor <NUM> contains metadata and location information corresponding to thirty two real memory cache lines, which is equivalent to 2KB of real memory. In the illustrated example, the <NUM>-byte descriptor <NUM> includes a thirty-two byte cache line map <NUM>, a sixteen byte segment allocator <NUM> and four sector pointers <NUM> totaling sixteen bytes (i.e., four sector pointers <NUM> each of four bytes). In this configuration, the STT <NUM> is metadata that is used by the MMC <NUM>, <NUM> or <NUM> to manage and track actual compressed physical memory.

The second section is the sector memory region <NUM>. This sector memory region <NUM> is divided into <NUM>-byte blocks <NUM> and is the actual memory (physical or real memory) that holds/stores operating system and application data and content. In one example, each STT entry can point to up to four of the blocks <NUM> for a maximum of <NUM> KB. If 2KB of real memory is all zero, then the corresponding STT entry points to zero blocks. In the case where the 2KB compression ratio is <NUM> (uncompressible), the STT entry points to four of the blocks <NUM>.

In various examples, a memory descriptor <NUM>, illustrated as an STT entry is implemented as shown in <FIG>. Each entry is divided into two main regions: a cache line map <NUM> and four sector pointers <NUM>. The four sector pointers <NUM> are four <NUM>-bit fields. Each field is a pointer to a <NUM>-byte memory sector that acts as storage of the compressed content of the cache lines. Depending on the compressibility ratio of the cache lines, zero to four sector pointers <NUM> can be used. In the case where all thirty-two cache lines associated with the STT entry are zero, all pointers <NUM> are null because the present disclosure uses an optimization technique to store the zero cache lines. On the other hand, if all the cache lines are not compressible or have very low compression ratio, all four pointers <NUM> point to physical memory sectors.

In one example, the first <NUM>-byte area of the STT entry is the cache line map <NUM> that contains cache line metadata, such as the size of each cache line, the location of the cache line in one of the sectors pointed to by the STT entry, as well as other flags. In the example illustrated in <FIG>, the <NUM>-byte map is divided into thirty-two twelve-bit fields <NUM>. The first three bits <NUM> are flags relating to the cache line. Bit <NUM> describes whether the cache line is allocated <NUM> or unallocated <NUM>. Bit <NUM> is <NUM> if the cache line is zero, otherwise the bit is <NUM>. Bit <NUM> is <NUM> if the cache line is uncompressed and <NUM> if the bit is compressed. The next two bits <NUM> (Bits <NUM>-<NUM>) specify the sector (from the possible four sectors) where cache line is stored. Each memory sector is logically divided into sixteen-byte segments. A compressed cache line uses zero to four segments for storage for that cache line. The next bits <NUM> (Bits <NUM>-<NUM>) are used to store the address (sixteen-byte aligned) of the compressed line within the sector. The final bits <NUM> (Bits <NUM>-<NUM>) are used to store the length of the cache line in sixteen-byte units. It should be noted that the trio (or triplet) of sector number (sector#), segment offset (cache segment#), and length uniquely identify the compressed cache line.

In operation, and with reference also to <FIG>, the MMC <NUM>, <NUM>, <NUM> is configured as a memory manager that receives a real address and zeros the least significant eleven bits to obtain the STT entry that contains all of the metadata that corresponds to the thirty-two cache lines associated with that entry. The MMC <NUM>, <NUM>, <NUM> loads the entry into the STLB <NUM>. In one example, bits <NUM>-<NUM> in the real address include the cache line number that is to be loaded. The MMC <NUM>, <NUM>, <NUM> locates the metadata flags, sector #, cache segment#, and length. The metadata has all the information for the MMC <NUM>, <NUM>, <NUM> to load the cache line from the physical memory into the L3 cache <NUM>. In one example, each physical memory access uses two memory reads. One read for reading the STT entry and a second read for the actual cache line. In some examples, to optimize physical memory access, an STLB cache is added to the MMC <NUM>, <NUM>, <NUM> to help reduce STT entry reads.

In one example, all free memory sectors are organized into a heap <NUM> (i.e., a free sector heap) as shown in <FIG> and that uses free sectors for storage. The heap <NUM> is accessed by a free list head <NUM>. In the example, each sector can store up to sixty-three pointers 702a to free sectors. The last eight bytes of the sector is a pointer <NUM> to the next sector containing the free sector pointers 702b. The MMC <NUM>, <NUM>, <NUM> in some examples includes a free sector register (illustrated as the free list head) that points to the first sector of the heap <NUM>. To optimize free sector allocation, in one example, the MMC <NUM>, <NUM>, <NUM> caches a few sectors (e.g., three or four sectors) of free memory sectors in the FSC <NUM>. As free memory sectors are consumed, the sectors used by the free sector heap are freed up and are also added to the heap <NUM>. Hence, the heap <NUM> does not consume any physical memory.

Other mechanisms are also used by the present disclosure. In some examples, the MMC <NUM>, <NUM>, <NUM> includes a set of registers that keep track of the data compression ratio, ratio of free to used physical memory sectors, etc. In addition, the MMC <NUM>, <NUM>, <NUM> includes a set of programmable interrupts to be used to generate events when certain counters are reached in some examples.

A method <NUM> to track compressed physical memory to allow compression of the physical memory using a cache compression algorithm is shown in <FIG>. For example, by implementing the method <NUM>, a cache compression algorithm can be used to compress DRAM at the cache line size. In some examples, physical memory compression and cache compression are used to compress inline physical memory. The operations illustrated in the flowchart described herein can be performed in a different order than is shown, can include additional or fewer steps and can be modified as desired or needed. Additionally, one or more operations can be performed simultaneously, concurrently, or sequentially.

More particularly, and with reference also to <FIG> and <FIG>, the method <NUM> includes accessing an STT defined by a descriptor at <NUM>. The descriptor in some examples includes a cache line map and sector pointers pointing to sector memory. For example, as described herein, the memory descriptor <NUM> includes the cache line map <NUM> and sector pointers <NUM>. As should be appreciated, the memory descriptor <NUM> can have different configurations that allow for compression at the cache line size.

The method <NUM> obtains from the cache line map, cache line metadata at <NUM>. The cache line metadata includes one or more flags, a sector number, a cache segment length, and the length of cache line. One example of a configuration of the metadata is illustrated in <FIG>. It should be appreciated that the order and size of each of the portions of the metadata can be varied as desired or needed. Each descriptor, in some examples, contains metadata and location information about thirty-two real memory cache lines, which is equivalent to 2KB of real memory.

The method <NUM> loads, at <NUM>, a cache line from physical memory into LLC based on the cache line metadata, wherein a compression block size is a single cache line. That is, the loading of the cache line allows for memory management at the cache line boundary to perform cache compression techniques to compress physical memory without using a compressed memory cache. With the metadata of the present disclosure, compressed physical memory is tracked to allow for use of cache compression techniques. For example, at <NUM>, physical memory is tracked using a plurality of cache lines. That is, the method allows for memory management of physical memory. In one example, the STT defined by the metadata is used by the MMC, <NUM>, <NUM>, 0r <NUM> to manage and track actual compressed physical memory.

It should be appreciated that the present disclosure and the examples described herein can be implemented in different environments. For example, the memory management and compression techniques described herein can be implemented in cloud computing environments. However, the present disclosure can be implemented in connection with any type of computing device or system, such as the computing device <NUM> illustrated in <FIG>.

<FIG> is a block diagram of an example computing device <NUM> for implementing aspects disclosed herein, and is designated generally as computing device <NUM>. The computing device <NUM> is but one example of a suitable computing environment and is not intended to suggest any limitation as to the scope of use or functionality of the examples disclosed herein. Neither should the computing device <NUM> be interpreted as having any dependency or requirement relating to any one or combination of components/modules illustrated. The examples disclosed herein may be described in the general context of computer code or machine-useable instructions, including computer-executable instructions such as program components, being executed by a computer or other machine, such as a personal data assistant or other handheld device. Generally, program components including routines, programs, objects, components, data structures, and the like, refer to code that performs particular tasks, or implement particular abstract data types. The discloses examples may be practiced in a variety of system configurations, including servers, personal computers, laptops, smart phones, mobile tablets, hand-held devices, consumer electronics, specialty computing devices, etc. The disclosed examples may also be practiced in distributed computing environments when tasks are performed by remote-processing devices that are linked through a communications network.

The computing device <NUM> includes a bus <NUM> that directly or indirectly couples the following devices: a computer-storage memory <NUM> (which includes physical memory, such as DRAM), one or more processors <NUM>, one or more presentation components <NUM>, input/output (I/O) ports <NUM>, I/O components <NUM>, a power supply <NUM>, and a network component <NUM>. While the computer device <NUM> is depicted as a seemingly single device, multiple computing devices <NUM> may work together and share the depicted device resources. For instance, the computer-storage memory <NUM> may be distributed across multiple devices, processor(s) <NUM> may provide housed on different devices, and so on.

The bus <NUM> represents what may be one or more busses (such as an address bus, data bus, or a combination thereof). Although the various blocks of <FIG> are shown with lines for the sake of clarity, in reality, delineating various components is not so clear, and metaphorically, the lines would more accurately be grey and fuzzy. For example, one may consider a presentation component such as a display device to be an I/O component. Also, processors have memory. Such is the nature of the art, and reiterate that the diagram of <FIG> is merely illustrative of an exemplary computing device that can be used in connection with one or more disclosed examples. Distinction is not made between such categories as "workstation," "server," "laptop," "hand-held device," etc., as all are contemplated within the scope of <FIG> and the references herein to a "computing device. " The computer-storage memory <NUM> may take the form of the computer-storage media references below and operatively provide storage of computer-readable instructions, data structures, program modules and other data for the computing device <NUM>. For example, the computer-storage memory <NUM> may store an operating system, a universal application platform, or other program modules and program data. The computer-storage memory <NUM> may be used to store and access instructions configured to carry out the various operations disclosed herein.

As mentioned below, the computer-storage memory <NUM> may include computer-storage media in the form of volatile and/or nonvolatile memory, removable or non-removable memory, data disks in virtual environments, or a combination thereof. And the computer-storage memory <NUM> may include any quantity of memory associated with or accessible by the computing device <NUM>. The memory <NUM> may be internal to the computing device <NUM> (as shown in <FIG>), external to the computing device <NUM> (not shown), or both (not shown). Examples of the memory <NUM> include, without limitation, random access memory (RAM); read only memory (ROM); electronically erasable programmable read only memory (EEPROM); flash memory or other memory technologies; CD-ROM, digital versatile disks (DVDs) or other optical or holographic media; magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices; memory wired into an analog computing device; or any other medium for encoding desired information and for access by the computing device <NUM>. Additionally, or alternatively, the computer-storage memory <NUM> may be distributed across multiple computing devices <NUM>, e.g., in a virtualized environment in which instruction processing is carried out on multiple devices <NUM>. For the purposes of this disclosure, "computer storage media," "computer-storage memory," "memory," and "memory devices" are synonymous terms for the computer-storage memory <NUM>, and none of these terms include carrier waves or propagating signaling.

The processor(s) <NUM> may include any quantity of processing units that read data from various entities, such as the memory <NUM> or I/O components <NUM>. Specifically, the processor(s) <NUM> are programmed to execute computer-executable instructions for implementing aspects of the disclosure. The instructions may be performed by the processor, by multiple processors within the computing device <NUM>, or by a processor external to the client computing device <NUM>. In some examples, the processor(s) <NUM> are programmed to execute instructions. Moreover, in some examples, the processor(s) <NUM> represent an implementation of analog techniques to perform the operations described herein. For example, the operations may be performed by an analog client computing device <NUM> and/or a digital client computing device <NUM>. Presentation component(s) <NUM> present data indications to a user or other device. Exemplary presentation components include a display device, speaker, printing component, vibrating component, etc. One skilled in the art will understand and appreciate that computer data may be presented in a number of ways, such as visually in a graphical user interface (GUI), audibly through speakers, wirelessly between computing devices <NUM>, across a wired connection, or in other ways. Ports <NUM> allow computing device <NUM> to be logically coupled to other devices including I/O components <NUM>, some of which may be built in. Examples I/O components <NUM> include, for example but without limitation, a microphone, joystick, game pad, satellite dish, scanner, printer, wireless device, etc..

The computing device <NUM> may operate in a networked environment via the network component <NUM> using logical connections to one or more remote computers. In some examples, the network component <NUM> includes a network interface card and/or computer-executable instructions (e.g., a driver) for operating the network interface card. Communication between the computing device <NUM> and other devices may occur using any protocol or mechanism over any wired or wireless connection. In some examples, the network component <NUM> is operable to communicate data over public, private, or hybrid (public and private) using a transfer protocol, between devices wirelessly using short range communication technologies (e.g., near-field communication (NFC), Bluetooth™ branded communications, or the like), or a combination thereof. For example, network component <NUM> communicates over a communication link <NUM> with a network <NUM>.

Although described in connection with an example computing device <NUM>, examples of the disclosure are capable of implementation with numerous other general-purpose or special-purpose computing system environments, configurations, or devices. Examples of well-known computing systems, environments, and/or configurations that may be suitable for use with aspects of the disclosure include, but are not limited to, smart phones, mobile tablets, mobile computing devices, personal computers, server computers, hand-held or laptop devices, multiprocessor systems, gaming consoles, microprocessor-based systems, set top boxes, programmable consumer electronics, mobile telephones, mobile computing and/or communication devices in wearable or accessory form factors (e.g., watches, glasses, headsets, or earphones), network PCs, minicomputers, mainframe computers, distributed computing environments that include any of the above systems or devices, VR devices, holographic device, and the like. Such systems or devices may accept input from the user in any way, including from input devices such as a keyboard or pointing device, via gesture input, proximity input (such as by hovering), and/or via voice input.

By way of example and not limitation, computer readable media comprise computer storage media and communication media. Computer storage media include volatile and nonvolatile, removable, and non-removable memory implemented in any method or technology for storage of information such as computer readable instructions, data structures, program modules, or the like. Computer storage media are tangible and mutually exclusive to communication media. Computer storage media are implemented in hardware and exclude carrier waves and propagated signals. Computer storage media for purposes of this disclosure are not signals per se. Exemplary computer storage media include hard disks, flash drives, solid-state memory, phase change random-access memory (PRAM), static random-access memory (SRAM), dynamic random-access memory (DRAM), other types of random-access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technology, compact disk read-only memory (CD-ROM), digital versatile disks (DVD) or other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other non-transmission medium that can be used to store information for access by a computing device. In contrast, communication media typically embody computer readable instructions, data structures, program modules, or the like in a modulated data signal such as a carrier wave or other transport mechanism and include any information delivery m.

A memory management system comprises a physical memory associated with a computing device; and a memory manager configured to manage a shared memory cache as part of a compression of the physical memory using a cache compression algorithm, wherein a compression block size for the compression is a single cache line size.

A computerized method for tracking compressed memory, the computerized method comprises accessing a sector translation table (STT) defined by a descriptor, the descriptor including a cache line map and a plurality of sector pointers pointing to sector memory; obtaining from the cache line map, cache line metadata relating to a cache line, the cache line metadata including one or more flags, a sector number, a cache segment length, and a length of the cache line; loading the cache line from physical memory into a last level cache (LLC) based on the cache line metadata, wherein a size of a compression block is the same as a size of a single cache line; and tracking compressed physical memory using a plurality of cache lines.

One or more computer storage media have computer-executable instructions to perform memory management that, upon execution by a processor, cause the processor to at least: access a sector translation table (STT) defined by a descriptor, the descriptor including a cache line map and a plurality of sector pointers pointing to sector memory; obtain from the cache line map, cache line metadata relating to a cache line, the cache line metadata including one or more flags, a sector number, a cache segment length, and a length of the cache line; load the cache line from physical memory into a last level cache (LLC) based on the cache line metadata, wherein a size of a compression block is the same as a size of a single cache line; and track compressed physical memory using a plurality of cache lines.

Any range or device value given herein can be extended or altered without losing the effect sought, as will be apparent to the skilled person.

It will be understood that the benefits and advantages described above can relate to one embodiment or can relate to several embodiments.

The embodiments illustrated and described herein as well as embodiments not specifically described herein but within the scope of aspects of the claims constitute exemplary means for memory compression. The illustrated one or more processors <NUM> together with the computer program code stored in memory <NUM> constitute exemplary processing means for managing the compression of memory as described herein.

In some examples, the operations illustrated in the figures can be implemented as software instructions encoded on a computer readable medium, in hardware programmed or designed to perform the operations, or both. For example, aspects of the disclosure can be implemented as a system on a chip or other circuitry including a plurality of interconnected, electrically conductive elements.

That is, the operations can be performed in any order, unless otherwise specified, and examples of the disclosure can include additional or fewer operations than those disclosed herein.

Claim 1:
A memory management system comprising:
a physical memory (<NUM>) associated with a computing device, wherein the physical memory comprises a sector translation table, STT, region (<NUM>) and a sector memory region (<NUM>);
a last level cache (<NUM>), LLC;
one or more additional caches (<NUM>);
a compressor/decompressor (<NUM>); and
a memory manager (<NUM>, <NUM>, <NUM>) configured to manage the physical memory and the LLC (<NUM>), the managing including a compression of the physical memory and of the LLC (<NUM>) using a cache compression algorithm, wherein
a compression block size for the compression is a single cache line size, and wherein the memory manager is further configured to use a memory descriptor (<NUM>, <NUM>) defined by a sector translation table, STT, entry, the memory descriptor having a cache line map (<NUM>, <NUM>) and a plurality of sector pointers (<NUM>, <NUM>) pointing to a sector (512B) in a sector memory region (<NUM>).