Processing device, storage management method and related equipment

Abstract

The embodiment of the invention discloses a processing device, a storage management method and related equipment. The device can comprise a processor core, a last-level cache LLC and a memory controller. The memory controller is used for receiving a first memory access request sent by the processor core and used for reading first data, and the first memory access request carries a first memory access address; reading memory access data from a memory coupled to the processing device based on the first memory access address; and if the memory access data comprises the first data and second data in a compressed state, sending the first data to the processor core through the LLC in response to the first memory access request, and caching the second data in the compressed state to the LLC. According to the processing device, the overhead of storage resources can be reduced on the basis of a memory bandwidth compression technology.

Description

Technical Field

[0001] This application relates to the field of memory access technology, and in particular to a processing device, memory management method and related equipment. Background Technology

[0002] Memory is one of the most important components of a computer, serving as the bridge for communication with the Central Processing Unit (CPU). All programs run within memory, therefore, memory performance has a significant impact on the computer's performance. Memory, also known as internal memory, is used to temporarily store data for CPU operations and for exchanging data with external storage devices such as hard drives. During computer operation, the CPU loads the necessary data into memory for processing, performs the calculations, and then sends the results back out. The operation of memory directly determines the stable operation of the computer.

[0003] In traditional technologies, systems increase the bandwidth between the system-on-chip (SoC) and memory by increasing the frequency or pin count of the memory interface. However, these technologies often incur energy consumption and area costs. Furthermore, interface changes are often slow because new memory standards are introduced only after long cycles. With the rapid increase in the number of cores in mainstream server processors, the memory wall is becoming increasingly pronounced. For example, the bandwidth between the L3 cache capacity and Double Data Rate SDRAM (DDR) on the SoC side has become a significant performance bottleneck.

[0004] Memory bandwidth compression technology is a technique used to improve the memory bandwidth of computer systems and is an effective method to solve system SoC bottlenecks. Specifically, memory bandwidth compression technology increases effective bandwidth by storing compressed data in memory, allowing the memory system to transmit data through fewer pins. However, existing memory bandwidth compression technologies have inherent overhead, including caching of data prefetched due to compression. For example, when the address length of a memory access request is less than the actual length of the compressed data stored at that address (or related addresses), extra data beyond the request is moved to on-chip space. Due to the locality of reference in the program, this type of data may be accessed quickly, so additional cache space is required for storage. However, when this data is not used, the space used for storing the data is wasted, unnecessarily occupying on-chip space. Summary of the Invention

[0005] This application provides a storage management method, apparatus, and related equipment that can reduce storage resource overhead while saving memory bandwidth.

[0006] In a first aspect, embodiments of this application provide a processing apparatus, which may include: a processor core, a last-level cache LLC, and a memory controller; the memory controller is configured to: receive a first memory access request sent by the processor core for reading first data, the first memory access request carrying a first memory access address; read memory access data from memory coupled to the processing apparatus based on the first memory access address; if the memory access data includes the first data and compressed second data, then in response to the first memory access request, send the first data to the processor core through the LLC, and cache the compressed second data in the LLC.

[0007] This application embodiment, based on memory bandwidth compression technology, adds an on-chip cache-side compression mechanism. That is, in addition to storing compressed data in the relevant memory, compressed data is also cached in the last-level cache (LLC) of the processing device to save on-chip storage resources. Specifically, this application embodiment provides a processing device that, when additional compressed data is read from memory due to the memory bandwidth compression mechanism, maintains the original compressed state of the additional compressed data for caching (i.e., stores it in a compressed state in the last-level cache). This effectively reduces on-chip storage resource overhead while saving memory bandwidth. Unlike existing technologies where compressed data read from memory needs to be cached on-chip in an uncompressed state, this application embodiment, after retrieving additional compressed data from memory, does not require decompression of the additional compressed data but caches it in its original compressed state in the LLC. If it is subsequently needed to read the compressed additional data from the LLC to the next-level cache, it can be read and decompressed. On the one hand, because the additional data is compressed, it saves bandwidth between on-chip and off-chip during the process of reading from memory (such as DDR) to the last level cache (such as L3) compared to uncompressed data. On the other hand, since the additional compressed data is cached in LLC form, it still maintains its original compressed state, thus saving LLC (such as L3) storage space. Moreover, the larger the amount of additional data read, the greater the benefit. For example, in some cases, when the memory access data read contains additional data beyond the first memory access request, and this additional data is compressed, it not only saves memory bandwidth and on-chip storage overhead for this memory access data, but also, considering the characteristics of program locality, the prefetched additional compressed data may be accessed soon. Therefore, it can increase the probability and efficiency of subsequent data being hit on-chip, reduce the number of memory accesses, and thus improve the overall performance of memory access. In summary, this application establishes a joint compression mechanism between the LLC and memory. By using the same preset compression rules to store compressed data in both the cache and memory, it achieves the effect of compressing two storage locations at once. This reduces the bandwidth between the on-chip system and the off-chip storage system, further reducing the data storage overhead of the System-on-Chip (SoC) and solving the technical problems of low compression ratio and low space utilization when compressing the cache and memory separately. Furthermore, the embodiments of this application do not require separate on-chip storage space, thus reusing the resources of the on-chip LLC and effectively reducing the on-chip chip area.

[0008] In one possible implementation, the memory access data further includes a compression flag indicating whether the second data is in a compressed state; the memory controller is further configured to cache the compression flag in the LLC.

[0009] In this embodiment, if the compressed data stored in memory carries a compression identifier indicating whether it is compressed, this compression identifier can be cached in the LLC along with the data itself. In this way, regardless of whether the data is on-chip or in memory, the compression status of the data at a certain address can be determined based on the compression identifier. When the compression identifier is cached in the LLC along with the data, the compression status of the corresponding data can be determined subsequently based on the compression identifier cached in the LLC, thus facilitating related read and write operations. For example, if it is necessary to read certain data from memory, the compression identifier can be used to determine whether the data needs to be decompressed or compressed.

[0010] In one possible implementation, if the first data is in a compressed state, the memory controller is specifically configured to: in response to the first memory access request, send the compressed first data to the LLC; the LLC is configured to receive and cache the compressed first data, read the cached compressed first data, decompress it, and then send it to the processor core; the LLC is configured to decompress the received compressed first data and then send it to the processor core; wherein, the compressed first data is obtained by compressing part or all of the original data corresponding to the first memory access address, and the compressed second data is obtained by compressing part or all of the original data corresponding to the second memory access address in the memory.

[0011] When the memory access data read from memory via a memory access request contains additional data beyond what is requested by the memory access address, and this additional data is compressed, this embodiment of the application will read the excess compressed data and store it in the LLC while maintaining its original compressed state. The reason for reading the additional data beyond what is requested by the memory access address is mainly due to the compressed state of the data stored in memory. For example, when the length of the memory access request (requesting 64B of original data, compressed to 32B) is less than the actual length of the compressed data (e.g., actual storage involves compressing two adjacent 64Bs into two 32Bs and storing them in the same memory unit), due to the granularity of the memory access (i.e., the smallest unit of data retrieved in a single memory access request, such as 64B), some additional data beyond the requested size will be moved to the on-chip space. Alternatively, due to an error in predicting the data compression state (originally predicted as 64B of uncompressed data, but actually 64B of compressed data), excess 32B of compressed data will be read onto the chip. When additional memory access data (such as adjacent data or adjacent compressed data) is read from memory due to reasons including, but not limited to, the embodiments of this application will read the extra compressed data in this instance and store it in L3 while maintaining the original compressed state. In this way, since the data reading usually has a certain continuity, when the additional memory access data needs to be read again, it is not necessary to read it from the on-chip memory (DDR). It is only necessary to read the compressed data from the on-chip LLC (such as L3) and decompress it to successfully hit the memory. On the one hand, it saves memory access times (previously two memory accesses were needed for the same amount of data, now only one is needed), meaning that the next time the extra data is needed, there is no need to access memory, thus resulting in higher hit efficiency. On the other hand, since the actual data that needs to be accessed is also in a compressed state (i.e., the first data is in a compressed state, or simply the first compressed data), both the actual data and the extra data (i.e., the second data in a compressed state, or simply the second compressed data) are cached in the LLC in their original compressed state, thus greatly saving on-chip cache storage overhead. Furthermore, since the read data has been compressed, memory bandwidth is saved compared to uncompressed data during the process of reading from memory to the LLC.

[0012] In one possible implementation, if the first data is in a compressed state, the memory controller is specifically configured to: in response to the first memory access request, send the compressed first data to the LLC; the LLC is configured to decompress the received compressed first data and then send it to the processor core; wherein the compressed first data is obtained by compressing part or all of the original data corresponding to the first memory access address, and the compressed second data is obtained by compressing part or all of the original data corresponding to the second memory access address in the memory.

[0013] When the memory access data read from memory via a memory access request contains additional data beyond what is requested by the memory access address, and this additional data is compressed, this embodiment of the application will read the extra compressed data and store it in the LLC in its original compressed state. However, since different caching mechanisms may have mutual exclusion mechanisms between different levels of cache, when there is a mutual exclusion mechanism between the LLC and its parent cache, the data actually requested by the memory access (i.e., the first compressed data, or simply the first compressed data) can be read from memory without being cached in the LLC, but directly cached in the parent cache of the LLC. Furthermore, since the first data read in this embodiment of the application is compressed, it can be decompressed by the LLC first and then cached in the parent cache of the LLC (i.e., it does not need to be cached in the LLC). For example, if the LLC is L3, and assuming there is a mutual exclusion mechanism between L3 and L2, then only one copy of the data needs to be kept between the two, while the other copy is not kept in the corresponding cache. In other words, after data is read from L3 and written to L2, L3 does not need to retain that data. Conversely, when data is read from L2 and written to L3, L2 also does not need to retain that data. Therefore, when data is read from memory, assuming the first compressed data is the data that actually needs to be read in this memory access request, and since the data requested by the processor core ultimately needs to be read into the processor core, that is, the first compressed data needs to be read from memory and cached in L2 → L1 → to reach the processor core. Therefore, if L3 and L2 are mutually exclusive, the first compressed data does not need to be cached in L3, but can be decompressed through LLC and then cached in L2 in an uncompressed state.

[0014] In one possible implementation, if the memory access data includes the first data and the first data is in a compressed state; the memory controller is further configured to: in response to the first memory access request, send the compressed first data to the LLC; the LLC is configured to receive and cache the compressed first data, read the cached compressed first data and decompress it before sending it to the processor core; or, the LLC is configured to decompress the received compressed first data before sending it to the processor core.

[0015] In this embodiment of the application, when the read memory access data includes compressed first data (also referred to as first compressed data) stored in a portion of the first memory access address, the first compressed data read is equivalent to the original data (i.e., the first data) corresponding to the first memory access address compressed by a preset compression rule. In this case, the first compressed data is stored in the LLC while maintaining its compressed state. Furthermore, in response to the first memory access request, the LLC reads the first compressed data cached by itself, then decompresses it and writes it to the next level cache, so as to finally send it to the processor core. For example, if the CPU core requests to read the raw data (i.e., 128B of uncompressed data) corresponding to the first memory access address, and if the raw data is compressed into 64B of compressed data and is actually stored in the lower 64B address of the 128B address, then a portion of the memory access address (i.e., the lower 64B address of the actual data stored in the 128B address) is read, and the first compressed data is cached in its original compressed state in the LLC. If the processor core needs to read this data later, it needs to write the data to the next higher level cache, that is, decompress the 64B of compressed data and write it to the next higher level cache.

[0016] In one possible implementation, if the memory access data includes the first data, and the first data is in an uncompressed state; the memory controller is further configured to: in response to the first memory access request, send the uncompressed first data to the LLC; the LLC is configured to receive and cache the uncompressed first data and send it to the processor core; or, the LLC is configured to send the received uncompressed first data to the processor core.

[0017] In this embodiment, when the read memory access data includes uncompressed data originally stored in memory in an uncompressed state, in one possible implementation, the uncompressed data can be directly stored in the LLC while maintaining its uncompressed state. This is because, in some scenarios, compressed or uncompressed data stored in memory is written from on-chip to memory. That is, if data can be compressed, it has already been compressed on-chip (LLC or memory controller) and written to memory; if data cannot be compressed, it is written to memory in an uncompressed state. Therefore, the compressed or uncompressed data stored in memory may already indicate whether the data can be compressed. Thus, when reading data from memory, it is no longer necessary to determine whether it can be compressed, because its current compression state already indicates whether the data can be compressed. Therefore, in this embodiment, it is not necessary to re-determine, and the data can be directly written to the LLC in its original uncompressed or compressed state in memory.

[0018] In one possible implementation, if the memory access data includes the first data, and the first data is in an uncompressed state; the memory controller is further configured to: in response to the first memory access request, send the uncompressed first data to the LLC; the LLC is configured to: if the uncompressed first data is compressible, compress and cache the received uncompressed first data, and send the uncompressed first data to the processor core; if the uncompressed first data is incompressible, receive and cache the uncompressed first data, and send the uncompressed first data to the processor core.

[0019] In this embodiment, when the read memory access data includes uncompressed data originally stored in memory in an uncompressed state, another possible implementation is to first determine whether the data can be compressed. If it can be compressed, the data is compressed before being stored in the LLC, and the compression rules are consistent with the compression rules of the compressed data in memory. This allows subsequent transmission between memory and LLC to maintain the original compressed state of the data. In other words, the data achieves the effect of compression once in the LLC (e.g., L3) and storage in memory (e.g., DDR), but stored in two different locations. If it cannot be compressed, it is stored in the LLC in an uncompressed state, and then directly written to the upper-level cache of the LLC before finally being sent to the processor core. This also takes into account that in some cases, some data may not be compressed when written from the LLC to memory, but when it is retrieved from memory and written back to the LLC, it may become compressible due to current bandwidth requirements or changes in data attributes. This results in a situation where data is not compressed when stored in memory, but needs to be recompressed when retrieved from memory and stored in the cache. Therefore, in this embodiment of the application, uncompressed data in memory can be compressed as much as possible as needed to maximize the data compression rate in the storage system and reduce bandwidth and storage overhead.

[0020] In one possible implementation, the memory controller stores a mapping relationship between address information and data compression information; the memory controller is specifically used to: determine the data compression information corresponding to the first memory access address based on the mapping relationship; and read the memory access data from the memory based on the first memory access address and the corresponding data compression information.

[0021] In this embodiment, the memory access system stores a mapping relationship between address information and data compression information. For example, it specifies whether an address is a high-order or low-order address within a compression unit. The data compression information includes whether the data is compressed, uncompressed, or not stored. Based on the address information of the first memory access address and the corresponding data compression information, it is possible to determine which data needs to be read from the first memory access address in this memory access request. It should be noted that normally, during memory access, only the data stored at the memory access address needs to be read. However, since this application is based on a memory bandwidth compression mechanism, there may be situations where the memory access address and the stored data do not strictly match. This is because the address occupied by some data changes after compression, and this change is related to the preset compression mechanism used in this application. That is, different compression algorithms may lead to different accurate correspondences between memory access addresses and data.

[0022] In one possible implementation, the storage granularity of the LLC is a cache line; the memory controller is specifically configured to: if it is determined that the first memory access address belongs to a first type of address, then read the memory access data stored in the first memory access address; the first type of address includes addresses whose address length is less than or equal to the cache line and which store data, or addresses whose address length is greater than the cache line and which store original data; or, if it is determined that the first memory access address belongs to a second type of address, then read the memory access data stored in the second memory access address; the second type includes addresses whose address length is less than or equal to the cache line and whose corresponding compressed data of the original data is stored in the second memory access address; or, if it is determined that the first memory access address belongs to a third type of address, then read the memory access data stored in a portion of the memory access addresses in the first memory access address; the third type of address includes addresses whose address length is greater than the cache line and whose corresponding compressed data of the original data is stored in the portion of the memory access addresses.

[0023] In this embodiment, because it is based on a memory bandwidth compression mechanism, in some cases, the data actually stored in the first memory access address may not be the original data corresponding to that address. In other words, the original data originally requested by the first memory access request may not be stored in the first memory access address. Therefore, the data requested by the first memory access request may be part or all of the data in the first memory access address, or it may be data from other addresses besides the first memory access address. In this embodiment, based on a preset compression mechanism, the type of the first memory access address is divided into three different cases according to the address from which the final memory access data is read:

[0024] In the first case, the memory access data is stored in the first memory access address. Examples include: 1. A request to read data from the lower 64 bytes is made; regardless of whether the data is compressed, the data at the first memory access address is read directly. 2. A request to read data from the upper 64 bytes is made; if the data is uncompressed, the data at the first memory access address is read directly. 3. A request to read 128 bytes of data is made; if the data is uncompressed, the data at the first memory access address is read directly. In case 1, the first memory access address stores the corresponding original data (i.e., the uncompressed first data) or compressed data (i.e., compressed first data and compressed second data) of the original data corresponding to the first and second memory access addresses. In cases 2 and 3, the first memory access address stores the corresponding original data (i.e., the uncompressed first data).

[0025] In the second case, no data is stored in the first memory access address, and the data is stored in the second memory access address. For example, in case 4, if a request is made to read data in the high 64B, and the data is compressed, then no data is stored in the high 64B, so the compressed data needs to be read from the low 64B (i.e., the second memory access address). In case 4 above, that is, the original data that should have been stored in the first memory access address is stored in other memory access addresses (such as the second memory access address) due to the memory bandwidth compression mechanism. In this case, reading the original data corresponding to the first memory access address needs to be read from the second memory access address. And usually in this case, the second memory access address also stores the original data corresponding to the second memory access address, that is, the second memory access address stores the compressed data of the original data corresponding to the first and second memory access addresses (i.e., the compressed first data and the compressed second data).

[0026] In the third case, the memory access data is stored in a portion of the first memory access address. For example, case 5: Request to read 128B of data. If the data is compressed, then read the data in a portion of the first memory access address. In case 5 above, the original data corresponding to the first memory access address is actually stored in a portion of the first memory access address. That is, the original data corresponding to the first memory access address (i.e., the uncompressed first data) is compressed and stored in a portion of the address segment of the first memory access address. In this case, to read the original data in the first memory access address, you only need to read the corresponding address in the first memory access address.

[0027] In one possible implementation, the apparatus further includes a cache above the LLC or a multi-level cache; the first memory access request further includes a third memory access address; the memory controller is further configured to: before reading memory access data from the memory based on the first memory access address, hit the data corresponding to the third memory access address from the LLC or the cache above the LLC or a multi-level cache.

[0028] In this embodiment of the application, when the processor (specifically, the processor core) initiates the first memory access request, in some possible cases, the first memory access request may contain an address that is longer than the first memory access address (i.e., an address that contains both the first memory access address and the third memory access address). However, since the data corresponding to the third memory access address has already been hit in L1, L2 or L3, it is necessary to search for the remaining data of the first memory access address in memory.

[0029] In one possible implementation, the apparatus further includes a cache above the LLC; the memory controller is further configured to: receive a second memory access request to write third data cached in the LLC to the cache above the LLC, and determine whether the third data is compressed data; the LLC is further configured to: if the third data is compressed, decompress the compressed third data and write the decompressed third data to the cache above the LLC; if the third data is uncompressed, write the uncompressed third data to the cache above the LLC.

[0030] In this embodiment, when it is necessary to request that data in LLC (such as L3) be written to the cache level above or above the previous level of LLC, the data needs to be read from LLC. Since LLC in this embodiment stores compressed data or uncompressed data compressed according to preset compression rules, it is necessary to first determine whether the data is compressed data. If it is compressed data, it needs to be decompressed before being written to the cache level above (because the CPU core ultimately needs to read the uncompressed raw data). If the data is uncompressed data, it is directly read and written to the cache level above, and then finally sent to the processor core.

[0031] In one possible implementation, the apparatus further includes a cache above the LLC; the memory controller is further configured to: receive a write-back request to cache the fourth data in the upper-level cache to the LLC; the LLC is further configured to: if the fourth data is compressible, compress the fourth data and cache the compressed fourth data to the LLC; if the fourth data is not compressible, cache the fourth data to the LLC.

[0032] In this embodiment, when data needs to be written (ejected, or replaced) from the parent cache to the LLC cache, it is necessary to first determine whether the data is compressible. If it is compressible, the data is compressed first and then cached in the LLC. If the data is incompressible, it is cached in an uncompressed state so that it can be directly stored in memory in either a compressed or uncompressed state later. That is, for a given piece of data, if it is compressible, it can be compressed in the LLC first, and when written to memory later, no further judgment or compression is needed; it can be written directly to memory in its compressed state. Conversely, if the data is incompressible, it is stored in the LLC in an uncompressed state, and when written to memory later, it can be written directly to memory in its uncompressed state without further judgment or compression.

[0033] In one possible implementation, the memory controller is further configured to: receive a third memory access request to write the fifth data cached in the LLC to the memory; the LLC is further configured to: if the fifth data is in a compressed state, write the compressed fifth data to the memory.

[0034] In this embodiment, when it is necessary to write the data cached in the last-level cache LLC to memory, it can first be determined whether the data is compressed data. If it is compressed data, it is also written to memory while maintaining its original compressed state, thereby realizing the function of compressing in one place and storing in multiple places. This not only saves bandwidth between on-chip (i.e., cache) and off-chip (i.e. memory), but also eliminates the need for repeated compression. This is because the LLC and memory are configured with the same compression mechanism, or in other words, the compression mechanism of memory covers the compression mechanism of cache. Therefore, repeated compression is unnecessary, further improving the efficiency of compressed data storage.

[0035] In one possible implementation, the LLC is further configured to: if the fifth data is in an uncompressed state, compress the fifth data and write the compressed fifth data into the memory; or, if the fifth data is in an uncompressed state, write the compressed fifth data into the memory.

[0036] In this embodiment, when data cached in the last-level cache LLC needs to be written to memory, it can be first determined whether the data is compressed. If it is uncompressed, the uncompressed data can be compressed before being sent to memory for storage. This reduces the bandwidth within the on-chip system and the bandwidth between on-chip and off-chip transmission. For example, in some possible embodiments, when the data to be written to memory is cached in the LLC in an uncompressed state, it can be further determined whether the data can be compressed. If it can be compressed, it can be further compressed in the on-chip memory controller before being stored in memory. That is, there may be some cases where the data cannot be compressed in the LLC, but it may be compressed in the memory controller before being written to memory. Optionally, in another possible implementation, the uncompressed data can be directly written to memory. This is because when the fifth data is cached in the LLC, it may have already been determined whether it can be compressed or not. If it cannot be compressed, it may be due to other reasons. Therefore, there is no need to perform a further determination or compression here, thus improving the efficiency of storage to memory.

[0037] In one possible implementation, the device further includes other LLCs; the memory controller is further configured to: receive a request to read, modify, or write sixth data in the LLC; if the sixth data meets a preset condition, determine whether seventh data is in the LLC or the other LLC, wherein the seventh data is data whose physical address is adjacent to the sixth data in memory; if the seventh data is in a target LLC, obtain the seventh data from the target LLC; determine the compression state of the sixth data and the seventh data in the memory based on the compression state of the seventh data; and write the sixth data and the seventh data into the memory based on the determined compression state.

[0038] In this embodiment of the application, when the memory access system receives a request to read, modify, and write a certain data (i.e., the sixth data) in LLC to memory, it needs to first determine whether the sixth data meets preset conditions. Optionally, it can determine whether the sixth data meets preset conditions by querying relevant information, such as the compression state of the sixth data itself, and the length and position (e.g., high or low bits) of the address corresponding to the sixth data. When it is determined based on the above relevant information that the length of the original address corresponding to the sixth data is less than or equal to the minimum unit of compressed storage (e.g., 64B), such as the sixth data being 64B of uncompressed data or 32B of compressed data, in some cases, whether the sixth data is read and modified in a compressed state or in an uncompressed state, and the address to which the sixth data is written after reading and modifying, may depend on the data with a physical address adjacent to it in memory (i.e., the seventh data). For example, if the sixth data is the high 64B of 128B aligned data, after compression, it may need to be stored together with the low 64B of the seventh data in the physical address of the seventh data. If the seventh data is incompressible, then the sixth data is also incompressible. In other words, it is necessary to refer to whether the seventh data associated with the sixth data can be compressed. For another example, if the sixth data is the low and high 64B of 128B aligned data, and it is determined that it is currently incompressible, but the address written back in the uncompressed state has already stored the compressed seventh data (the original high 64B data), then if the seventh data and its compression status are not obtained first, the sixth data cannot be written back in the uncompressed state. In other words, in this case, it is necessary to refer to the compression status and storage address of the seventh data associated with the sixth data. However, if the seventh data is stored in memory, the data needs to be read from memory, which not only increases the on-chip and off-chip bandwidth but also reduces the efficiency of data storage. Therefore, in this embodiment, the eighth data is preferentially searched in other LLCs in the processing device. The reason is that in the processing device of this embodiment, the last level cache and memory corresponding to different processor cores are interconnected and shared. Therefore, the seventh data may be cached in other LLCs. If the seventh data can be obtained from other LLCs, the additional memory bandwidth overhead caused by read-write can be reduced, and the read-write efficiency can be improved.

[0039] In one possible implementation, the memory controller includes a first compression module and a first decompression module; the LLC includes a second compression module and a second decompression module; the first compression module is used to compress uncompressed data stored in the memory that needs to be compressed; the second decompression module is used to decompress compressed data retrieved from the memory that needs to be decompressed; the second compression module is used to compress uncompressed data cached in the LLC that needs to be compressed; and the second decompression module is used to decompress compressed data retrieved from the LLC that needs to be decompressed.

[0040] In this embodiment of the application, both the memory controller and the LLC may include corresponding compression and decompression modules, which can be used to compress or decompress relevant data under different processes, different memory access stages (e.g., reading data, writing data, reading-modifying-writing data), or different compression granularity requirements.

[0041] In one possible implementation, the first compression module and the second compression module use the same preset compression rules to compress the data.

[0042] In this embodiment, the compression modules in the memory controller and LLC use the same compression algorithm (i.e., compression mechanism) to compress the data. Correspondingly, the decompression modules in the memory controller and LLC also use the same decompression algorithm (i.e., the same decompression mechanism) to decompress the data. Optionally, the preset compression rules in the memory controller may include, but are not limited to, the preset compression rules in the LLC. That is, the compression and decompression modules in the memory controller may have more possible compression methods and granularities, as well as corresponding decompression methods and granularities, than the LLC.

[0043] Secondly, embodiments of this application provide a storage management method, which may include: receiving a first memory access request sent by a processor core for reading first data, the first memory access request carrying a first memory access address; reading memory access data from memory coupled to the processor core based on the first memory access address; if the memory access data includes the first data and compressed second data, then in response to the first memory access request, sending the first data to the processor core and caching the compressed second data in the LLC.

[0044] In one possible implementation, the memory access data further includes a compression flag indicating whether the second data is in a compressed state; the method further includes caching the compression flag in the LLC.

[0045] In one possible implementation, if the first data is in a compressed state, sending the first data to the processor core includes: in response to the first memory access request, sending the compressed first data to the LLC; receiving and caching the compressed first data through the LLC, reading the cached compressed first data and decompressing it before sending it to the processor core; or, decompressing the received compressed first data through the LLC before sending it to the processor core; wherein the compressed first data is obtained by compressing part or all of the original data corresponding to the first memory access address, and the compressed second data is obtained by compressing part or all of the original data corresponding to the second memory access address in the memory.

[0046] In one possible implementation, if the memory access data includes the first data and the first data is in a compressed state, the method further includes: in response to the first memory access request, sending the compressed first data to the LLC; receiving and caching the compressed first data through the LLC, reading the cached compressed first data and decompressing it before sending it to the processor core; or, decompressing the received compressed first data through the LLC before sending it to the processor core.

[0047] In one possible implementation, if the memory access data includes the first data, and the first data is in an uncompressed state; the method further includes: in response to the first memory access request, sending the uncompressed first data to the LLC; receiving and caching the uncompressed first data through the LLC and sending it to the processor core; or, sending the received uncompressed first data to the processor core through the LLC.

[0048] In one possible implementation, if the memory access data includes the first data, and the first data is in an uncompressed state; the method further includes: in response to the first memory access request, sending the uncompressed first data to the LLC; if the uncompressed first data is compressible, then compressing and caching the received uncompressed first data through the LLC, and sending the uncompressed first data to the processor core; if the uncompressed first data is incompressible, then receiving and caching the uncompressed first data through the LLC, and sending the uncompressed first data to the processor core.

[0049] In one possible implementation, reading memory access data from memory coupled to the processor core based on the first memory access address includes: determining data compression information corresponding to the first memory access address based on a pre-stored mapping relationship; the mapping relationship includes a mapping relationship between address information and data compression information; and reading the memory access data from the memory based on the first memory access address and the corresponding data compression information.

[0050] In one possible implementation, the storage granularity of the LLC is a cache line; the step of reading the memory access data from the memory based on the first memory access address and the corresponding data compression information includes: if it is determined that the first memory access address belongs to a first type of address, then reading the memory access data stored in the first memory access address; the first type of address includes addresses whose address length is less than or equal to the cache line and which store data, or addresses whose address length is greater than the cache line and which store original data; or, if it is determined that the first memory access address belongs to a second type of address, then reading the memory access data stored in the second memory access address; the second type includes addresses whose address length is less than or equal to the cache line and whose corresponding compressed data is stored in the second memory access address; or, if it is determined that the first memory access address belongs to a third type of address, then reading the memory access data stored in a portion of the memory access addresses in the first memory access address; the third type of address includes addresses whose address length is greater than the cache line and whose corresponding compressed data is stored in the portion of the memory access addresses.

[0051] In one possible implementation, the first memory access request further includes a third memory access address; the method further includes: before reading memory access data from the memory based on the first memory access address, hitting the data corresponding to the third memory access address from the LLC or the cache of the LLC at one or more levels above it.

[0052] In one possible implementation, the method further includes: receiving a second memory access request to write third data cached in the LLC to the upper-level cache; determining whether the third data is compressed data; if the third data is compressed, decompressing the compressed third data through the LLC and writing the decompressed third data to the upper-level cache; if the third data is uncompressed, writing the uncompressed third data to the upper-level cache through the LLC.

[0053] In one possible implementation, the method further includes: receiving a write-back request to cache the fourth data in the previous level cache to the LLC; if the fourth data is compressible, compressing the fourth data through the LLC and caching the compressed fourth data to the LLC; if the fourth data is not compressible, caching the fourth data to the LLC through the LLC.

[0054] In one possible implementation, the method further includes: receiving a third memory access request to write the fifth data cached in the LLC to the memory; if the fifth data is in a compressed state, then writing the compressed fifth data to the memory through the LLC.

[0055] In one possible implementation, the method further includes: if the fifth data is in an uncompressed state, then compressing the fifth data through the LLC and writing the compressed fifth data into the memory; or, if the fifth data is in an uncompressed state, then writing the compressed fifth data into the memory through the LLC.

[0056] In one possible implementation, the method further includes: receiving a request to read, modify, and write sixth data in the LLC; if the sixth data meets a preset condition, determining whether seventh data is in the LLC or another LLC, wherein the seventh data is data whose physical address is adjacent to the sixth data in memory; if the seventh data is in a target LLC, obtaining the seventh data from the target LLC; determining the compression state of the sixth data and the seventh data in the memory based on the compression state of the seventh data; and writing the sixth data and the seventh data into the memory based on the determined compression state.

[0057] Thirdly, embodiments of this application provide a system-on-a-chip (SoC) that may include the processing apparatus provided by any of the implementations of the first aspect described above.

[0058] Fourthly, this application provides a semiconductor chip that may include the processing apparatus provided by any of the implementations of the first aspect described above.

[0059] Fifthly, this application provides a chip system including the processing apparatus provided by any implementation of the first aspect described above. In one possible design, the chip system further includes a memory for storing program instructions and data necessary or related to the operation of the chip system. The chip system may be composed of chips or may include chips and other discrete devices.

[0060] Sixthly, this application provides an electronic device that has the function of implementing any of the storage management methods described in the second aspect above. This function can be implemented by hardware or by hardware executing corresponding software. The hardware or software includes one or more modules corresponding to the above-described function.

[0061] Seventhly, this application provides an electronic device including the processing apparatus provided in any of the implementations of the first aspect described above. In one possible design, the electronic device further includes a memory for storing program instructions and data necessary or related to the operation of the electronic device. The chip system may be composed of chips or may include chips and other discrete devices.

[0062] Eighthly, this application provides a processing apparatus having the function of implementing any of the storage management methods described in the second aspect above. This function can be implemented in hardware or by hardware executing corresponding software. The hardware or software includes one or more modules corresponding to the aforementioned function.

[0063] Ninthly, this application provides a terminal device, which includes a processing device, wherein the processing device is provided by any implementation of the first aspect described above. The terminal device may further include a memory coupled to the processing device, which stores necessary program instructions and data of the terminal device. The terminal device may also include a communication interface for communicating with other devices or communication networks.

[0064] In a tenth aspect, this application provides a computer-readable storage medium storing a computer program that, when executed by multiple electronic devices, implements the storage management method flow described in any one of the second aspects above.

[0065] In one aspect, embodiments of this application provide a computer program including instructions that, when executed by an electronic device, enable the electronic device to perform the storage management method flow described in any of the second aspects above. Attached Figure Description

[0066] Figure 1A This is a schematic diagram of a system architecture for a multi-level management scheme.

[0067] Figure 1B This is a schematic diagram of the system architecture for an on-chip cache compression scheme.

[0068] Figure 2A This is a schematic diagram of the structure of a processing device provided in an embodiment of this application.

[0069] Figure 2B This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application.

[0070] Figure 2C This is a schematic diagram of the structure of another electronic device provided in the embodiments of this application.

[0071] Figure 2D This is a schematic diagram illustrating an example of cache line compression provided in an embodiment of this application.

[0072] Figure 3A This is a schematic diagram of a physical memory space partitioning provided in an embodiment of this application.

[0073] Figure 3B This is a schematic diagram of physical page address partitioning provided in an embodiment of this application.

[0074] Figure 3C This is a schematic diagram of a 128B aligned high 64B and low 64B according to an embodiment of this application.

[0075] Figure 4A This is a schematic diagram illustrating the mapping relationship between data and addresses before and after compression, provided as an embodiment of this application.

[0076] Figure 4B This is a schematic diagram illustrating another mapping relationship between data and addresses before and after compression, provided for an embodiment of this application.

[0077] Figure 4C This is a schematic diagram illustrating another mapping relationship between data and addresses before and after compression, provided as an embodiment of this application.

[0078] Figure 4D This is a schematic diagram illustrating another mapping relationship between data and addresses before and after compression, provided as an embodiment of this application.

[0079] Figure 5A This is a flowchart illustrating a process for handling a 128B read request, provided as an embodiment of this application.

[0080] Figure 5B This is a flowchart illustrating a 64B read request processing method provided in an embodiment of this application.

[0081] Figure 5C This is a flowchart illustrating a process for handling a 128B write request, provided as an embodiment of this application.

[0082] Figure 5D This is a flowchart illustrating a 64B write request processing method provided in an embodiment of this application.

[0083] Figure 6 This is a flowchart illustrating a storage management method provided in an embodiment of this application. Detailed Implementation

[0084] The embodiments of this application will now be described with reference to the accompanying drawings. The terms "first," "second," "third," and "fourth," etc., in the specification, claims, and accompanying drawings of this application are used to distinguish different objects, not to describe a specific order. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion. For example, a process, method, system, product, or device that includes a series of steps or units is not limited to the listed steps or units, but may optionally include steps or units not listed, or may optionally include other steps or units inherent to these processes, methods, products, or devices. The reference to "embodiment" herein means that a specific feature, structure, or characteristic described in connection with an embodiment may be included in at least one embodiment of this application. The appearance of this phrase in various places in the specification does not necessarily refer to the same embodiment, nor is it a separate or alternative embodiment mutually exclusive with other embodiments. It will be explicitly and implicitly understood by those skilled in the art that the embodiments described herein can be combined with other embodiments.

[0085] As used in this specification, the terms "component," "module," "system," etc., are used to refer to computer-related entities, hardware, firmware, combinations of hardware and software, software, or software in execution. For example, a component can be, but is not limited to, a process running on a processor, a processor, an object, an executable file, an execution thread, a program, and / or a computer. As illustrated, applications running on computing devices and computing devices can both be components. One or more components may reside in a process and / or an execution thread, and components may be located on a single computer and / or distributed among two or more computers. Furthermore, these components can be executed from various computer-readable media on which various data structures are stored. Components can communicate, for example, via local and / or remote processes based on signals having one or more data packets (e.g., data from two components interacting with another component between a local system, a distributed system, and / or a network, such as the Internet interacting with other systems via signals).

[0086] First, some of the terms used in this application will be explained to facilitate understanding by those skilled in the art.

[0087] (1) An integrated circuit (IC) is a miniature electronic device or component. Using certain processes, the transistors, resistors, capacitors, inductors, and other components required for a circuit, along with interconnected wiring, are fabricated on a small piece or several small pieces of semiconductor wafers or dielectric substrates, and then packaged in a casing to form a miniature structure with the required circuit function; that is, an IC chip is an integrated circuit formed by placing a large number of microelectronic components (transistors, resistors, capacitors, etc.) on a plastic substrate to make a chip.

[0088] (2) Read Modify Write (RMW) is a basic operation on memory, which can include read operation, write operation, or read modify write operation. Read modify write operation means first reading the data in memory, modifying it, and then writing it back into memory.

[0089] (3) Double Data Rate (DDR) memory, also known as DDR SDRAM, is commonly referred to as DDR. SDRAM stands for Synchronous Dynamic Random Access Memory. The "synchronous" aspect refers to the fact that the memory requires a synchronous clock for operation; internal command transmission and data transfer are based on this clock. DDR is a storage device that loses data when power is off and requires periodic refresh to maintain data integrity. The DDR SDRAM subsystem consists of three parts: the DDR controller, the DDR PHY, and the DRAM memory chips.

[0090] (4) Static Random-Access Memory (SRAM) is a type of random access memory. The term "static" means that the data stored in this type of memory is permanently retained as long as power is supplied. In contrast, the data stored in Dynamic Random-Access Memory (DRAM) needs to be updated periodically. However, when the power supply is interrupted, the data stored in SRAM will still be lost (this is called volatile memory), unlike ROM or flash memory which can retain data even after power is lost.

[0091] (5) NAND-flash memory is a non-volatile memory based on NAND technology. Compared with traditional Flash memory, NAND Flash has higher storage density, lower power consumption and longer life.

[0092] (6) Metadata, also known as intermediary data or relay data, is data about data. It primarily describes data properties and supports functions such as indicating storage location, historical data, resource lookup, and file records. Metadata is a type of electronic catalog. To achieve the purpose of cataloging, it is necessary to describe and collect the content or characteristics of the data, thereby assisting in data retrieval. In the embodiments of this application, metadata can be used to record information related to whether the data is compressed. For example, metadata records whether a piece of data is compressed or uncompressed.

[0093] (7) bit: A computer can convert 0 and 1 into signals in a circuit for calculation. A bit is the smallest unit for storing and moving data in a computer. It has only two values, 0 and 1. Its abbreviation is the lowercase letter "b".

[0094] (8) Byte. Byte is the English word for byte. Its abbreviation is the uppercase letter "B". English characters usually take one byte, which is 1B. Chinese characters usually take more than 2 bytes due to character set limitations. Conversion relationship: 8 bits equals 1 byte. One byte equals eight bits.

[0095] (9) The memory wall refers to the phenomenon where memory performance severely limits CPU performance. The main performance indicators of memory are "bandwidth" and "latency".

[0096] First, to facilitate understanding of the embodiments of this application, the specific technical problem to be solved by this application is further analyzed and proposed. Currently, there are various technical solutions for implementing bandwidth compression technology; two examples are listed below:

[0097] Option 1: Multi-level Management Solution

[0098] like Figure 1A As shown, Figure 1A This is a system architecture diagram of a multi-level management scheme, which includes the following components:

[0099] (1) Compress the prefetched data using an additional prefetch buffer.

[0100] (2) Supports compression with multiple granularities.

[0101] The disadvantages of Option 1:

[0102] (1) Compression of DDR bandwidth specifically for memory.

[0103] (2) Additional prefetch buffer space is required.

[0104] (3) A lot of read-modify-write operations are required to update the compressed state, which becomes particularly noticeable in multi-granularity compression.

[0105] Option 2: Compression caching scheme

[0106] like Figure 1B As shown, Figure 1B This is a schematic diagram of the system architecture for an on-chip cache compression scheme. The scheme explores various forms of cache compression, including supporting more data by adding block tags and using superblocks to avoid adding extra tags.

[0107] The disadvantages of Option 2:

[0108] (1) Compress the cache separately.

[0109] (2) Without DDR compression, although the superblock has low overhead, the L3 compression rate is low and the performance gain is limited.

[0110] In summary, both of the existing compression techniques have their own shortcomings and cannot achieve a balance between bandwidth and storage space overhead; for example, they suffer from excessive space overhead. Therefore, this application comprehensively considers the deficiencies of existing methods and provides a joint optimization mechanism of LLC caching and memory compression to solve the above-mentioned technical problems. Specifically, the technical problems to be solved by this application include one or more of the following aspects: providing a memory management scheme that improves the effective bandwidth between the on-chip system and memory while minimizing storage space overhead (such as on-chip storage space) and improving the efficient management of compressed data.

[0111] Based on the above, please refer to Figure 2A , Figure 2A This is a schematic diagram of a processing device provided in an embodiment of this application. The processing device 10 can be a system-on-a-chip (SoC), specifically including a processor core 101, a last-level cache 104, and a memory controller 105. Please refer to... Figure 2B , Figure 2BThis is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. The electronic device 001 may include the aforementioned processing device 10, and optionally, may also include memory 20. The processing device 10 or electronic device 001 may be located in any electronic device, such as a computer, mobile phone, tablet, smart wearable device, or other similar devices. Specifically, the processing device 10 or electronic device 001 may also be a chip, chipset, or a circuit board carrying a chip or chipset. The chip, chipset, or circuit board carrying a chip or chipset can operate under necessary software drivers. The processing device 10 or electronic device 001 containing the processing device 10 in this embodiment of the application can be applied in memory systems, including general-purpose servers, high-performance (HPC) servers, artificial intelligence (AI) servers, mobile devices, terminal devices, or memory control modules of terminal devices. The processing device 10 or electronic device 001 in this embodiment of the application, when deployed in relevant scenarios, can significantly reduce memory access bandwidth and on-chip storage resource overhead. It should be noted that the processing device 10 in this application can be a system-on-a-chip (SoC) or a module in the electronic device 001 mentioned above. The following example uses SoC 10 as the processing device 10.

[0112] Further, please see Figure 2C , Figure 2C This is a schematic diagram of another electronic device provided in an embodiment of this application. The electronic device 001 includes a SoC 10 (taking the processing device 10 as an example of a SoC 10), memory 20, and external memory 30. The SoC 10 includes, for example,... Figure 2C The multi-core CPU 100 and memory controller 105 shown herein, exemplarily, include multiple CPU cores (e.g., CPUCore101-1, CPU Core 101-2...CPU Core 101-N), a Level 1 cache (L1 Cache 102-1, L1 Cache 102-2...L1 Cache 102-N) corresponding to each CPU core, a Level 2 cache (L2 Cache 103-1, L2 Cache 103-2...L2 Cache 103-N) corresponding to each CPU core, and an L3 cache 104 shared by the multiple CPU cores.

[0113] The above Figure 2A , Figure 2B or Figure 2C The SoC 10 in this application can be a dedicated integrated circuit that contains a complete system and all embedded software. Exemplarily, the functional modules specifically included in the SoC 10 in this embodiment are described below:

[0114] Multiple CPU cores: These may include CPUCore101-1, CPU Core 101-2, ..., CPU Core 101-N. Multiple CPU cores are the core component of the SoC, responsible for performing various computational and control tasks. For example, CPUCore101-1 can run an operating system or application to control multiple hardware or software components connected to it, and can process various data and perform operations; furthermore, CPUCore101-1 can load instructions or data from external memory 30 into memory 20 (see [link to documentation]). Figure 2C The CPU can initiate various memory access requests to memory 20 as needed (e.g., read data requests, write data requests, read-modify-write requests, etc.). Optionally, different CPU cores in a multi-core CPU can be used to perform different functions or the same function. For example, multiple CPU cores can be one or more of the following: Central Processing Unit (CPU), Application Processing Unit (AP), Modem / Demodulation Unit, Graphics Processing Unit (GPU), Image Signal Processor (ISP), Video Encoding / Decoding Unit, Digital Signal Processor (DSP), Baseband Processing Unit, and Neural-Network Processing Unit (NPU). Optionally, registers can also be set in each CPU core to store instructions and data.

[0115] Each CPU core corresponds to a Level 1 cache (L1 Cache): such as Figure 2C The diagram may include L1 Cache 102-1, L1 Cache 102-2...L1 Cache 102-N. In Figure 2C In a CPU, the Level 1 cache is the cache closest to the CPU core, and the L1 cache is exclusive to each CPU core (also known as a kernel, CPU Core, etc.). For example, L1 can be logically divided, such as into two parts: a data cache and an instruction cache, that is, one part stores data and the other part stores instructions.

[0116] The L2 cache (L2) corresponding to each CPU core: such as Figure 2C The diagram may include L2 Cache 103-1, L2 Cache 103-2...L2 Cache 103-N. In Figure 2CIn this context, the L2 cache is also dedicated to each CPU core. Optionally, in some processor architectures, CPU cores can share the L2 cache.

[0117] The Last Level Cache (LLC) 104, located immediately after main memory, is the L1 cache situated between the processor core and main memory, and is the closest cache to main memory. It is used to improve the performance of the memory hierarchy. Optionally, the LLC 104 in this embodiment also has the function of compressing uncompressed data and decompressing compressed data. Specifically, the LLC includes a first compression module 1041 and a first decompression module 1042 for compressing or decompressing data cached in or read from the LLC. Figure 2C In the example shown, LLC stands for Level 3 Cache (L3). It is understood that the specific cache level corresponding to LLC may differ in different processor architectures (depending on the system cache architecture, LLC may be a Level 2 cache, Level 3 cache, Level 4 cache, etc.; this application does not specifically limit this). For ease of explanation, the following descriptions will primarily use L3 as an example to illustrate the relevant functions of LLC, but this does not constitute a limitation on LLC. Figure 2C As shown, L3 can be shared by all CPU cores (such as CPUCore101-1, CPU Core 101-2...CPUCore 101-N) on the entire SoC 10. In this embodiment, L3 can act as a prefetch buffer for memory 20 (such as DDR). For example, L3 can be used to store additional data obtained due to compression. For example, if a memory access request hits in L3, the data is directly read from L3 and the request is returned; if the original memory access request is 64 bytes, and 64 bytes of compressed data is read from memory, the data corresponding to the memory access and the additional data read can be cached in the original compressed state in L3Cache104. Optionally, the compression algorithm and data format are the same as those in memory when compressing data in L3, and L3 is used as a prefetch buffer for DDR. When data in DDR needs to be read, the compressed data can be directly obtained from L3.

[0118] The first compression module (Compression Engine, CE) 1041 can be used to compress data cached in an LLC that requires compression. In this embodiment, the LLC (e.g., L3) supports compressing the high 64B and low 64B of a 128B-aligned cache separately and then merging them into a single 64B. Optionally, when the compression range is constrained to 128B alignment, the L3 cache does not need to store additional tags due to the increased equivalent capacity; only an additional 2-bit overhead is required to record the compression status and tags. Please refer to [link to relevant documentation]. Figure 2D , Figure 2D This is a schematic diagram illustrating an example of cache line compression provided in an embodiment of this application. For example, cache line Way1 in L3 stores compressed data A and compressed data A+1, cache line Way2 stores compressed data C, cache line Way3 stores uncompressed data E, and cache line Way4 stores compressed data D. Assuming the cache line size is 64B, then A and A+1 can be 32B data compressed from 64B data, and C and D can also be 32B data compressed from 64B data. E is 64B uncompressed data. Optionally, the first compression module 1041 in this embodiment can support mixed-granularity compression to effectively increase the compression ratio. For example, mixed granularity includes compressing 128B data to 64B, and compressing two 64B data into 32B respectively. Correspondingly, decompression supports decompressing 64B into 128B, and decompressing two independent 32B data into 64B respectively.

[0119] The first decompression module (Decompression Engine, DCE) 1042 is used to decompress compressed data read from L3 and requiring decompression. Optionally, it can decompress 64B into 128B, or it can decompress two independent 32B into 64B respectively.

[0120] Optionally, the first compression module 1041 and the first decompression module 1042 may also be located in the upper-level cache of the LLC, or between the LLC and the upper-level cache of the LLC. This application embodiment does not specifically limit this.

[0121] The L1, L2, and L3 caches mentioned above are high-speed caches, integrated within the CPU. Depending on whether they store instructions or data, caches can be further categorized as I-cache and D-cache. For example, a cache can store instructions or data that the CPU has recently used or that are frequently used. If the CPU needs to use the same instruction or data again, it can retrieve it directly from the cache, avoiding repeated accesses, reducing CPU wait time, and thus improving system efficiency. Optionally, each CPU core can also have its own unique register, accessible only to that CPU core and inaccessible to other CPU cores.

[0122] Memory 20, also known as internal memory, main memory, or main storage, is the internal memory that directly exchanges data with the CPU. Memory can be considered a transfer station between external storage (such as a hard drive) and the CPU. Memory 20 is typically a power-loss volatile memory, losing its stored content when power is off. In this embodiment, memory 20 refers to readable and writable running memory, which can be used to temporarily store computational data from the multi-core CPU 100, exchange data with external storage 30 or other external storage, and serve as a storage medium for temporary data of the operating system or other running programs. For example, the operating system running on CPUCore 101-1 loads the data to be processed from memory 20 to CPUCore 101-1 for computation, and then CPUCore 101-1 sends the result back after the computation is complete. Since all programs need to be loaded into memory 20 before CPUCore 101-1 can run, optionally, besides the multi-core CPU 100, other accelerators ( Figure 2C (Not shown in the diagram, such as AI processors, graphics processors, etc.) can also share memory 20, but not L3 Cache 104. That is, the accelerator can directly access memory 20 without first accessing L3, but directly access memory 20 (such as DDR). Therefore, the compression mechanism in DDR can have a wider range than the L3 compression mechanism, because L3 compression granularity may only be cacheline, but memory can have cacheline granularity, and also granularity multiples of cacheline granularity. In other words, L3 only supports cacheline-level compression, while memory can support both cacheline-level compression and compression multiples of cacheline granularity.

[0123] The memory 20 can specifically be one or more of the following: Dynamic Random Access Memory (DRAM), Static Random Access Memory (SRAM), and Synchronous Dynamic Random Access Memory (SDRAM). Among them, DRAM includes Double Data Rate Synchronous Dynamic Random Access Memory (DDR SDRAM), abbreviated as DDR, second-generation Double Data Rate Synchronous Dynamic Random Access Memory (DDR2), third-generation Double Data Rate Synchronous Dynamic Random Access Memory (DDR3), fourth-generation Low Power Double Data Rate Synchronous Dynamic Random Access Memory (LPDDR4), or fifth-generation Low Power Double Data Rate Synchronous Dynamic Random Access Memory (LPDDR5), etc.

[0124] like Figure 2CAs shown, in terms of the distance of data from the CPU core and the speed of data transmission, the general order is: CPU registers > L1 > L2 > L3 > memory; in terms of memory storage space, the general order is: memory > L3 > L2 > L1 > registers. For example, in this embodiment, the process of the multi-core CPU 100 reading data is as follows: Taking CPU Core 101-1 as an example, CPU Core 101-1 first searches in L1 Cache 102-1. If not found, it searches in L2 Cache 103-1. If not found, it searches in L3 Cache 104. If not found, it searches in memory. Furthermore, the read data cannot be immediately stored in the registers; it is first stored in L3 Cache 104, then copied to L2 Cache 103-1 and L1 Cache 102-1, and finally read into the registers of CPU Core 101-1. In other words, data read from memory is first placed in L3, then copied from L3 to L2, then from L2 to L1, and finally copied from L1 to the CPU's registers. The CPU ultimately accesses memory from these registers. It's important to note that different caching mechanisms may have mutual exclusion between L3 and L2, or between L3 and memory. If such mutual exclusion exists, based on the data reading order, only one copy is retained between the mutually exclusive caches or memory, and the other copy is not retained in the corresponding cache. For example, when data is read from L3 and written to DDR, L3 will no longer retain that data. Similarly, if L3 and L2 are mutually exclusive, data read from L3 and written to L2 does not need to be retained in L3, and vice versa. In actual embodiments, whether the read data is retained in the original cache varies depending on the caching mechanism, and this application does not specifically limit this.

[0125] The memory controller (DMC) 105 manages various types of memory in the electronic device 001, such as main memory 20 and caches (L1 cache, L2 cache, L3 cache), and is responsible for data exchange between the CPU core and main memory 20, data reading and writing, memory allocation, and management. Optionally, the memory controller 105 can be a logic function module with corresponding functions, such as a logic state machine, or it can be a corresponding software implementation executed on relevant hardware. For example, the memory controller 105 receives and parses read commands, write commands, or read-modify-write commands sent by the CPU, and resolves the logical address of the data carried in the relevant command into a physical address according to a fixed address mapping relationship, thereby finding the location of the data to be read or written, and finally sending a control signal corresponding to the command to the main memory 20. Furthermore, since the solution in this application is based on memory bandwidth compression technology, and compression functionality is typically absent in the on-chip memory 20, the compressed data stored in the on-chip memory 20 is because it was already compressed on-chip before being written into memory 20. In other words, the memory controller 105 in this embodiment has the function of compressing or decompressing data. From a bandwidth perspective, reading 128B of data, if it is compressed data, consumes 64B of bandwidth; if it is uncompressed data, reading 128B consumes 128B of bandwidth. Optionally, the memory controller 105 may include a second compression module 1051, a second decompression module 1052, a compression status management submodule 1053, a read / write submodule 1054, and a memory read / write submodule 1055.

[0126] The second compression engine (CE) 1051 and the second decompression engine (DCE) 1052: In this embodiment, the same compression algorithm and compression granularity are used for LLC and memory (such as DDR). For example, the compression algorithm compresses 64B into 32B, and correspondingly, the decompression algorithm decompresses 32B into 64B.

[0127] The second compression module 1051 can function identically to the first compression module 1041 in the LLC (e.g., L3). The second compression module 1051 in the memory controller 105 can be used to compress uncompressed data to be written to the memory 20 and requiring compression. Optionally, the second compression module 1051 in the memory controller 105 supports overall compression of the 128B, as well as compression of the high 64B and low 64B aligned to the 128B, respectively.

[0128] The second decompression module 1052 can function identically to the first decompression module 1042 in the LLC (e.g., L3). The second decompression module 1052 in the memory controller 105 can be used to decompress compressed data read from the memory 20 that needs to be decompressed. Optionally, the decompression supports decompressing 64B to 128B, and decompressing two independent 32B data points to 64B respectively.

[0129] Compression State Management Submodule 1053: This application embodiment does not make any special assumptions about the function of compression state management. For ease of explanation, this application embodiment can use a metadata cache for compression state management. It is understood that this application embodiment can also combine compression state prediction mechanism, which will not be elaborated here. Unlike LLC, since the compression state of the off-chip space needs to be recorded on-chip to complete the address and length conversion, an additional structure is needed to manage the compression state of off-chip data. That is, in this application embodiment, the compression state management submodule 1053 can manage the compression state of data in memory.

[0130] The read-modify-write submodule 1054 works in conjunction with LLCs (such as L3) to establish a path for requesting data from the LLCs. If data is found on-chip (including other LLCs in the memory access system), it requests the data from the corresponding LLC (such as L3) to avoid increasing the bandwidth burden on memory (such as DDR).

[0131] Memory read / write submodule 1055: If the memory (e.g., DDR) returns data in a compressed state, it maintains the compressed state and passes it to the LLC (e.g., L3) for storage. If the LLC (e.g., L3) replaces the data with compressed data, it maintains the compressed state and passes it to the memory (e.g., DDR).

[0132] Since both the LLC and the memory controller 105 have compression / decompression functions, the timing of compression or decompression by the LLC and the timing of compression or decompression by the memory controller 105 are independent of each other. However, in some possible situations, such as needing to compress 128B into 64B, where the LLC may not support this compression granularity, the second compression / decompression module in the memory controller 105 can perform the corresponding compression or decompression. Therefore, the scope of the compression mechanism in the memory controller 105 can cover and exceed the scope of the compression mechanism in the LLC. For example, writing from the outside to L3 can be compressed by L3, and writing from the cache to DDR can also be compressed by the memory controller. The specific functions of the memory controller 105 involved in this embodiment will be described in subsequent embodiments.

[0133] It is understood that, in addition to the main functional modules mentioned above, the SoC 10 may also include other functional modules such as accelerators, security modules, power management units, touch controllers, and various interface controllers. These modules cooperate to provide the various functions and performance of the SoC, which will not be listed here. In summary, the SoC in this application embodiment is a chip that integrates multiple functional modules. These functional modules cooperate to provide the SoC with various functions such as computing, graphics, communication, multimedia, and sensing. It is understood that the internal structure and function of the SoC may differ in different application scenarios or different electronic devices, and this application embodiment does not specifically limit this.

[0134] Further, please see Figure 2C The electronic device 001 may also include an external memory 30, wherein,

[0135] External storage 30 is typically non-volatile memory, meaning its contents are not lost after power failure. In this application, external storage 30 may include read-only memory (ROM) for storing system information and boot programs, and readable and writable external storage (such as Flash) for storing programs and data. Its function is to store instructions and data long-term. For example, system information includes system files such as the Linux kernel and Android operating system; programs may include built-in system applications (such as app stores, wallet applications, security centers, etc.) that come pre-installed with the electronic device 001 and applications downloaded and installed by the user later (such as social applications, video applications, mobile payment applications, game applications, etc.); data may include system data related to system operation (such as configuration file data, log file data, cache data, etc.), and data generated during user use (such as fingerprint data, chat history data, photo and video data, etc.). It is understood that data access to external storage 30 (such as a disk) is not directly from the disk to the CPU, but rather through memory as a bridge to achieve fast access.

[0136] The external storage 30 may include one or more of the following: one-time programmable read-only memory (OTPROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), mask read-only memory, flash read-only memory, universal flash storage (UFS), flash memory (e.g., NAND flash, NOR flash, etc.), hard disk drive or solid-state drive (SSD).

[0137] It is understood that the structures illustrated in the embodiments of this application do not constitute a specific limitation on the processing device (such as SoC 10) or electronic device 001. In other embodiments of this application, SoC 10 or electronic device 001 may include more or fewer components than illustrated, or combine some components, or split some components, or have different component arrangements. The illustrated components may be implemented in hardware, software, or a combination of software and hardware.

[0138] Based on the above Figures 2A-2D The structure of any possible SoC 10 or electronic device 001 is described in detail, and the memory management functions specifically implemented by the SoC 10 or electronic device 001 in the embodiments of this application may include the following:

[0139] The memory controller 105 is configured to receive a first memory access request sent by the processor core for reading first data, the first memory access request carrying a first memory access address; read memory access data from memory coupled to the processing device based on the first memory access address; if the memory access data includes the first data and compressed second data, then in response to the first memory access request, send the first data to the processor core through the LLC, and cache the compressed second data in the LLC.

[0140] LLC 104 is configured to send the first data to the processor under the instruction of the memory controller 105, and to receive and cache the compressed second data.

[0141] Specifically, when the memory controller 105 receives the first memory access request from the multi-core CPU 100 (e.g., any one of the CPU cores), the CPU's data reading process is as follows: first, it searches in the L1 cache; if not found, it searches in the L2 cache; if still not found, it searches in the L3 cache; and if still not found, it searches in main memory. Therefore, in this embodiment, if the first memory access request issued by the processor does not find a complete cache hit (including partial and complete misses), it needs to search for some or all of the data in main memory. Furthermore, since this embodiment is based on a memory bandwidth compression mechanism, the memory 20 may store compressed data and uncompressed data compressed according to a preset compression rule. Therefore, the data read from memory in response to the first memory access request may not necessarily be the original data corresponding to the first memory access address. It may read the original data corresponding to the first memory access address (i.e., the first data), or it may read the original data (i.e., the first data) along with additional data (i.e., the second data). In other words, the memory access data read in response to the first memory access request may vary depending on the first memory access address, whether the corresponding data is compressed, and the preset compression mechanism. In other words, the memory access data at least includes the original data corresponding to the first memory access address in the first memory access request (i.e., the original data corresponding to that address), which may be in a compressed state or an uncompressed state. Furthermore, the read memory access data may not be read from the first memory access address. It may be read from the first memory access address, or it may be an address associated with the first memory access address, or it may be a part of the first memory access address. The reason is that the memory in this application embodiment involves compressed data stored in memory. Therefore, in some cases, the data may be stored at other addresses because the storage address occupied after compression is smaller.

[0142] Furthermore, after reading the memory access data, it is necessary to determine the compression status of the memory access data. If the read memory access data contains additional data in a compressed state, the original compressed state of the additional data is directly cached in the LLC. Optionally, since the ultimate goal of the first memory access request is to write the requested data into the CPU, after reading the memory access data from memory, it is necessary to further copy the data actually requested by the first memory access request in an uncompressed state to L2, then to L1, and finally write it into the CPU to complete the response to the first memory access request. Therefore, the data actually requested by the first memory access request in the memory access data (that is, the original data corresponding to the first memory access address) can be cached in the LLC first and then read into the upper-level cache of the LLC, or directly written into the upper-level cache of the LLC (without caching it in the LLC first). This depends on whether there is a mutual exclusion mechanism between different levels of cache. Therefore, the processing method of the data actually requested by the first memory access request is not specifically limited in this embodiment. Optionally, if the data actually requested by the first memory access request is also compressed, it can be cached in the LLC in its compressed state, just like extra data, or it can be directly decompressed and cached in the cache level above the LLC. From the perspective of the read process, in the prior art, the L3 cache based on the memory bandwidth compression mechanism can only store uncompressed data. However, in the embodiments of this application, the L3 cache can store compressed data. That is, after the processor issues a read request, the compressed data read from memory such as DDR does not need to be decompressed before being stored in the cache or prefetch cache, as in the prior art. Instead, it can be directly stored in the L3 cache in its original compressed format. This method increases the storage capacity in the L3 cache, effectively increasing the amount of data stored in the on-chip system and improving the cache hit rate.

[0143] This application embodiment, based on memory bandwidth compression technology, adds an on-chip cache-side compression mechanism. That is, in addition to storing compressed data in the relevant memory, compressed data is also cached in the last-level cache (LLC) of the processing device to save on-chip storage resources. Specifically, this application embodiment provides a processing device that, when additional compressed data is read from memory due to the memory bandwidth compression mechanism, maintains the original compressed state of the additional compressed data for caching (i.e., stores it in a compressed state in the last-level cache). This effectively reduces on-chip storage resource overhead while saving memory bandwidth. Unlike existing technologies where compressed data read from memory needs to be cached on-chip in an uncompressed state, this application embodiment, after retrieving additional compressed data from memory, does not require decompression of the additional compressed data but caches it in its original compressed state in the LLC. If it is subsequently needed to read the compressed additional data from the LLC to the next-level cache, it can be read and decompressed. On the one hand, because the additional data is compressed, it saves bandwidth between on-chip and off-chip during the process of reading from memory (such as DDR) to the last level cache (such as L3) compared to uncompressed data. On the other hand, since the additional compressed data is cached in LLC form, it still maintains its original compressed state, thus saving LLC (such as L3) storage space. Moreover, the larger the amount of additional data read, the greater the benefit. For example, in some cases, when the memory access data read contains additional data beyond the first memory access request, and this additional data is compressed, it not only saves memory bandwidth and on-chip storage overhead for this memory access data, but also, considering the characteristics of program locality, the prefetched additional compressed data may be accessed soon. Therefore, it can increase the probability and efficiency of subsequent data being hit on-chip, reduce the number of memory accesses, and thus improve the overall performance of memory access. In summary, this application establishes a joint compression mechanism between the LLC and memory. By using the same preset compression rules to store compressed data in both the cache and memory, it achieves the effect of compressing two storage locations at once. This reduces the bandwidth between the on-chip system and the off-chip storage system, further reducing the data storage overhead of the System-on-Chip (SoC) and solving the technical problems of low compression ratio and low space utilization when compressing the cache and memory separately. Furthermore, the embodiments of this application do not require separate on-chip storage space, thus reusing the resources of the on-chip LLC and effectively reducing the on-chip chip area.

[0144] The reason why compression ratios are low when caching and memory are compressed separately is that, in some cases, data that could be compressed might be deemed uncompressible and thus stored in memory in an uncompressed state. However, using the combined compression method based on LLC and memory as described in this application, the state of some data can be more clearly and easily obtained, thus increasing the probability of data compression. For example, if some data stored in LLC is in a compressed state, then only the compressibility of the other half of the data needs to be determined to compress both sets of data. However, if caching and memory are compressed separately as in existing technologies, the complexity of determining whether these two sets of data can be compressed simultaneously increases, and in some cases, they might be deemed uncompressible, ultimately resulting in low compression ratios for data in memory or LLC.

[0145] In some possible implementations, the memory access data further includes a compression flag indicating whether the second data is compressed; the memory controller is further configured to cache the compression flag in the LLC. Optionally, all data cached in L3 of this application embodiment carries its own tag indicating whether the data is compressed. Upon a hit, it is known whether the data is compressed or uncompressed. If it is compressed, the compressed data is decompressed within L3 by the first decompression module. For example, a hit means address segment matching, and the address segment contains a record of whether each cacheline is compressed or uncompressed. This hit process (and determination of whether the data is compressed) is performed by the memory controller. After decompression, it can be sent to L2. In this application embodiment, if the compressed data stored in memory carries a compression flag indicating whether it is compressed, the compression flag can be cached in the LLC along with the data itself. In this way, regardless of whether the data is on-chip or in memory, the compression status of the data at a certain address can be determined based on the compression flag. When the compression flag is cached in the LLC along with the data, the compression status of the corresponding data can be determined based on the compression flag cached in the LLC, thus facilitating related read and write operations. For example, if it is necessary to read certain data from memory, the compression flag can be used to determine whether the data needs to be decompressed or compressed.

[0146] In some possible implementations, when the memory access data includes compressed data, reading the memory access data from memory and caching that memory access data into the LLC can specifically include one or more of the following two cases:

[0147] (i) The memory access data includes compressed data, and this memory access data contains compressed data that is not included in this memory access request:

[0148] (1) In one possible implementation, it is assumed that the LLC and its parent cache are not mutually exclusive:

[0149] When it is determined that the memory access data includes compressed first data (which may be referred to as first compressed data for ease of description) and compressed second data (which may be referred to as second compressed data for ease of description), the memory controller is specifically configured to: in response to the first memory access request, send the compressed first data to the LLC; the LLC is configured to receive and cache the compressed first data, read the cached compressed first data and decompress it before sending it to the processor core;

[0150] Specifically, the first data is the original uncompressed data corresponding to the first memory access address, and the second data is the original uncompressed data corresponding to the second memory access address. The first memory access address and the second memory access address are different addresses in memory. In this embodiment, both the first memory access address and the second memory access address are physical addresses. Optionally, the first memory access address and the second memory access address can be adjacent physical addresses in memory. For example, caching the prefetched compressed data may be because when the length of the memory access request is less than the actual length of the compressed data stored, additional data outside the request may be moved to the on-chip space. Due to the locality of reference of the program, this type of data may be accessed quickly, so additional cache space is required for storage. However, when this data is not used, the space used to store the data will be wasted, unnecessarily occupying on-chip space. Therefore, in this embodiment, the prefetched data is cached in its original compressed state to reduce the waste of on-chip storage space. For example, when the memory controller determines that the data read from memory (such as DDR) is 64 bytes of compressed data, consisting of two compressed data points A1 and A2, if the caching mechanism is that L3 and L2 are not mutually exclusive (i.e., data available in L2 must also be available in L3), then the entire compressed data (A1+A2) can be cached in L3. A1 can then be read from L3, decompressed, and written to L2. Optionally, the decompression can be performed by either the decompression module in L3 or the decompression module in L2, thus saving bandwidth between on-chip paths. When the processor needs to read the second data later, it can directly obtain it from L3, avoiding DDR memory access and improving hit efficiency without increasing on-chip storage overhead.

[0151] When the memory access data read from memory via a memory access request contains additional data beyond what is requested by the memory access address, and this additional data is compressed, this embodiment of the application will read the excess compressed data and store it in the LLC while maintaining its original compressed state. The reason for reading the additional data beyond what is requested by the memory access address is mainly due to the compressed state of the data stored in memory. For example, when the length of the memory access request (requesting 64B of original data, compressed to 32B) is less than the actual length of the compressed data (e.g., actual storage involves compressing two adjacent 64Bs into two 32Bs and storing them in the same memory unit), due to the granularity of the memory access (i.e., the smallest unit of data retrieved in a single memory access request, such as 64B), some additional data beyond the requested size will be moved to the on-chip space. Alternatively, due to an error in predicting the data compression state (originally predicted as 64B of uncompressed data, but actually 64B of compressed data), excess 32B of compressed data will be read onto the chip. When additional memory access data (such as adjacent data or adjacent compressed data) is read from memory due to reasons including, but not limited to, the embodiments of this application will read the extra compressed data in this instance and store it in L3 while maintaining the original compressed state. In this way, since the data reading usually has a certain continuity, when the additional memory access data needs to be read again, it is not necessary to read it from the on-chip memory (DDR). It is only necessary to read the compressed data from the on-chip LLC (such as L3) and decompress it to successfully hit the memory. On the one hand, it saves memory access times (previously two memory accesses were needed for the same amount of data, now only one is needed), meaning that the next time the extra data is needed, there is no need to access memory, thus resulting in higher hit efficiency. On the other hand, since the actual data that needs to be accessed is also in a compressed state (i.e., the first data is in a compressed state, or simply the first compressed data), both the actual data and the extra data (i.e., the second data in a compressed state, or simply the second compressed data) are cached in the LLC in their original compressed state, thus greatly saving on-chip cache storage overhead. Furthermore, since the read data has been compressed, memory bandwidth is saved compared to uncompressed data during the process of reading from memory to the LLC.

[0152] (2) In another possible implementation, it is assumed that the LLC and its parent cache are mutually exclusive:

[0153] The memory controller is specifically configured to: in response to the first memory access request, send compressed first data to the LLC; the LLC is configured to decompress the received compressed first data and then send it to the processor core;

[0154] For example, when the memory controller determines that the data read from memory (such as DDR) is 64 bytes of compressed data, including two compressed data A1+A2, if the caching mechanism is L3 and L2 mutually exclusive (data in L2 cannot be in L3), then after L3 caches A1, it directly decompresses (bypasses) A1 and writes it to L2 without saving it itself. Optionally, this decompression can be performed by the decompression module in L3 or L2, thus saving bandwidth between on-chip paths. When the processor needs to read the second data later, it can directly obtain it from L3, avoiding DDR memory access and improving hit efficiency without increasing on-chip storage overhead.

[0155] When the memory access data read from memory via a memory access request contains additional data beyond what is requested by the memory access address, and this additional data is compressed, this embodiment of the application will read the extra compressed data and store it in the LLC in its original compressed state. However, since different caching mechanisms may have mutual exclusion mechanisms between different levels of cache, when there is a mutual exclusion mechanism between the LLC and its parent cache, the data actually requested by the memory access (i.e., the first compressed data, or simply the first compressed data) can be read from memory without being cached in the LLC, but directly cached in the parent cache of the LLC. Furthermore, since the first data read in this embodiment of the application is compressed, it can be decompressed by the LLC first and then cached in the parent cache of the LLC (i.e., it does not need to be cached in the LLC). For example, if the LLC is L3, and assuming there is a mutual exclusion mechanism between L3 and L2, then only one copy of the data needs to be kept between the two, while the other copy is not kept in the corresponding cache. In other words, after data is read from L3 and written to L2, L3 does not need to retain that data. Conversely, when data is read from L2 and written to L3, L2 also does not need to retain that data. Therefore, when data is read from memory, assuming the first compressed data is the data that actually needs to be read in this memory access request, and since the data requested by the processor core ultimately needs to be read into the processor core, that is, the first compressed data needs to be read from memory and cached in L2 → L1 → to reach the processor core. Therefore, if L3 and L2 are mutually exclusive, the first compressed data does not need to be cached in L3, but can be decompressed through LLC and then cached in L2 in an uncompressed state.

[0156] (ii) The memory access data includes compressed data, but this memory access data only contains the original data actually requested in this memory access request:

[0157] In one possible implementation, if the memory access data includes the first data and the first data is in a compressed state; the memory controller is further configured to: in response to the first memory access request, send the compressed first data to the LLC; the LLC is configured to receive and cache the compressed first data, read the cached compressed first data and decompress it before sending it to the processor core; or, the LLC is configured to decompress the received compressed first data before sending it to the processor core.

[0158] In this embodiment of the application, when the read memory access data includes compressed first data (also referred to as first compressed data) stored in a portion of the first memory access address, the first compressed data read is equivalent to the original data (i.e., the first data) corresponding to the first memory access address compressed by a preset compression rule. In this case, the first compressed data is stored in the LLC while maintaining its compressed state. Furthermore, in response to the first memory access request, the LLC reads the first compressed data cached by itself, then decompresses it and writes it to the next level cache, so as to finally send it to the processor core. For example, if the CPU core requests to read the raw data (i.e., 128B of uncompressed data) corresponding to the first memory access address, and if the raw data is compressed into 64B of compressed data and is actually stored in the lower 64B address of the 128B address, then a portion of the memory access address (i.e., the lower 64B address of the actual data stored in the 128B address) is read, and the first compressed data is cached in its original compressed state in the LLC. If the processor core needs to read this data later, it needs to write the data to the next higher level cache, that is, decompress the 64B of compressed data and write it to the next higher level cache.

[0159] In some possible implementations, when the memory access data includes uncompressed data, reading the memory access data from memory and caching it in the LLC can specifically include one or more of the following two cases:

[0160] (i) If the data accessed includes uncompressed data, then a further determination is made based on whether the data is compressible:

[0161] In one possible implementation, if the memory access data includes the first data, and the first data is in an uncompressed state; the memory controller is further configured to: in response to the first memory access request, send the uncompressed first data to the LLC; optionally, further determine whether the first data is compressible; the LLC is configured to: if the uncompressed first data is compressible, compress and cache the received uncompressed first data, and send the uncompressed first data to the processor core; if the uncompressed first data is not compressible, receive and cache the uncompressed first data, and send the uncompressed first data to the processor core.

[0162] For example, when the first memory access address belongs to the first type of address, and this first type of address includes the address corresponding to 64B of uncompressed data or the address corresponding to 128B of uncompressed data, when reading data from DDR, if the data is in an uncompressed state, it is necessary to determine whether the data can be compressed. If it can be compressed, the data can be compressed according to a preset compression rule and stored in LLC. This preset compression rule is consistent with the compression rule in memory, so that subsequent data transmission can be carried out according to the preset compression rule. That is, data only needs to be compressed once according to a unified standard between L3 and DDR, without multiple compressions, thus achieving the effect of one compression for both places.

[0163] In this embodiment, when the read memory access data includes uncompressed data originally stored in memory in an uncompressed state, another possible implementation is to first determine whether the data can be compressed. If it can be compressed, the data is compressed before being stored in the LLC, and the compression rules are consistent with the compression rules of the compressed data in memory. This allows subsequent transmission between memory and LLC to maintain the original compressed state of the data. In other words, the data achieves the effect of compression once in the LLC (e.g., L3) and storage in memory (e.g., DDR), but stored in two different locations. If it cannot be compressed, it is stored in the LLC in an uncompressed state, and then directly written to the upper-level cache of the LLC before finally being sent to the processor core. This also takes into account that in some cases, some data may not be compressed when written from the LLC to memory, but when it is retrieved from memory and written back to the LLC, it may become compressible due to current bandwidth requirements or changes in data attributes. This results in a situation where data is not compressed when stored in memory, but needs to be recompressed when retrieved from memory and stored in the cache. Therefore, in this embodiment of the application, uncompressed data in memory can be compressed as much as possible as needed to maximize the data compression rate in the storage system and reduce bandwidth and storage overhead.

[0164] (ii) If the data accessed includes uncompressed data, then the data will be cached directly in its original state:

[0165] In one possible implementation, if the memory access data includes the first data, and the first data is in an uncompressed state; the memory controller is further configured to: in response to the first memory access request, send the uncompressed first data to the LLC; the LLC is configured to receive and cache the uncompressed first data and send it to the processor core; or, the LLC is configured to send the received uncompressed first data to the processor core.

[0166] Specifically, in this embodiment of the application, for the case where the memory access data is uncompressed data, it is considered that if it can be compressed, it has already been compressed when written to DDR. If a piece of data is stored in an uncompressed state in the on-chip DDR, that is, it has not been compressed, then it is assumed that the data is likely not compressible. Therefore, when the memory access data is uncompressed data and is read from memory, it is not necessary to perform a judgment and operation on whether it is compressed.

[0167] In this embodiment, when the read memory access data includes uncompressed data originally stored in memory in an uncompressed state, in one possible implementation, the uncompressed data can be directly stored in the LLC while maintaining its uncompressed state. This is because, in some scenarios, compressed or uncompressed data stored in memory is written from on-chip to memory. That is, if data can be compressed, it has already been compressed on-chip (LLC or memory controller) and written to memory; if data cannot be compressed, it is written to memory in an uncompressed state. Therefore, the compressed or uncompressed data stored in memory may already indicate whether the data can be compressed. Thus, when reading data from memory, it is no longer necessary to determine whether it can be compressed, because its current compression state already indicates whether the data can be compressed. Therefore, in this embodiment, it is not necessary to re-determine, and the data can be directly written to the LLC in its original uncompressed or compressed state in memory.

[0168] Regarding how to read the memory access data corresponding to the first memory access request from memory based on the first memory access address, in one possible implementation, the memory controller stores a mapping relationship between address information and data compression information; the memory controller is specifically used to: determine the data compression information corresponding to the first memory access address based on the mapping relationship; and read the memory access data from memory based on the first memory access address and the corresponding data compression information.

[0169] Specifically, the memory controller 105 determines the data compression information corresponding to the first memory access address based on the mapping relationship between address information and data compression information stored in the compression state management submodule 1053. For example, the address information of the first memory access address includes the address length and whether the address is a high-order or low-order address; the data compression information corresponding to the first memory access address includes whether the address corresponds to compressed or uncompressed data. For instance, when the first memory access address is a 128-byte address and its corresponding data compression state is compressed, according to the preset compression mechanism in this embodiment (e.g., the preset compression mechanism includes compressing the data to the low-order bits at half the compression ratio instead of the high-order bits), it can be determined that the memory access data corresponding to the 128-byte length needs to be read from the lower 64 bytes of the 128-byte address. As another example, when the first memory access address is a 64-byte address and its corresponding data compression state is uncompressed, according to the preset compression mechanism in this embodiment, it can be determined that the memory access data corresponding to the 64-byte length is directly read from the 64-byte location. For example, when the first memory access address is a 64-byte address, the corresponding data compression state is compressed, and the 64-byte is the low-order bit in the compression unit, then according to the preset compression mechanism in the embodiment of this application, it can be determined that the memory access data corresponding to the 64-byte length is directly read from the 64-byte position, and at this time, the extra data stored in the address due to compression will be read.

[0170] In this embodiment, the memory access system stores a mapping relationship between address information and data compression information. For example, it specifies whether an address is a high-order or low-order address within a compression unit. The data compression information includes whether the data is compressed, uncompressed, or not stored. Based on the address information of the first memory access address and the corresponding data compression information, it is possible to determine which data needs to be read from the first memory access address in this memory access request. It should be noted that normally, during memory access, only the data stored at the memory access address needs to be read. However, since this application is based on a memory bandwidth compression mechanism, there may be situations where the memory access address and the stored data do not strictly match. This is because the address occupied by some data changes after compression, and this change is related to the preset compression mechanism used in this application. That is, different compression algorithms may lead to different accurate correspondences between memory access addresses and data.

[0171] Since this application is based on a memory bandwidth compression mechanism, in some cases, the data actually stored in the first memory access address may not be the original data corresponding to that address. In other words, the original data originally requested by the first memory access request may not be stored in the first memory access address. Therefore, for the data requested by the first memory access request, it may be reading part or all of the data in the first memory access address, or it may be reading data from other addresses besides the first memory access address. In this embodiment, based on a preset compression mechanism, the type of the first memory access address is divided into three different cases according to the address where the final memory access data is read. That is, the memory controller 105 reads the memory access data corresponding to the first memory access address from the memory based on the first memory access address and the corresponding data compression information, which may specifically include one or more of the following three cases:

[0172] (i) In one possible implementation, the storage granularity of the LLC is a cache line; the memory controller is specifically used for:

[0173] If it is determined that the first memory access address belongs to the first type of address, then the memory access data stored in the first memory access address is read; the first type of address includes addresses whose address length is less than or equal to the cache line and which store data, or addresses whose address length is greater than the cache line and which store original data.

[0174] Specifically, in the first type of case described above, the memory access data is stored in the first memory access address, for example, including: 1. Requesting to read data in the lower 64B, regardless of whether the data is compressed, the data in the first memory access address is read directly; 2. Requesting to read data in the upper 64B, if the data is uncompressed, the data in the first memory access address is read directly; 3. Requesting to read 128B of data, if the data is uncompressed, the data in the first memory access address is read directly; In case 1 above, the first memory access address stores its corresponding original data (i.e., the uncompressed first data), or stores compressed data of the original data corresponding to the first memory access address and the second memory access address (i.e., compressed first data and compressed second data); In cases 2 and 3 above, the first memory access address stores its corresponding original data (i.e., the uncompressed first data);

[0175] (ii) In one possible implementation, the storage granularity of the LLC is a cache line; the memory controller is specifically used for:

[0176] If it is determined that the first memory access address belongs to the second type of address, then the memory access data stored in the second memory access address is read; the second type includes addresses whose address length is less than or equal to the cache line, and whose corresponding compressed data of the original data is stored in the second memory access address.

[0177] Specifically, in the second type of case described above, no data is stored in the first memory access address, and the memory access data is stored in the second memory access address. For example, this includes: 4. Requesting to read data in the high 64B. If the data is compressed, no data is stored in the high 64B, so the compressed data needs to be read from the low 64B (i.e., the second memory access address). In case 4 above, that is, the original data that should have been stored in the first memory access address is stored in other memory access addresses (such as the second memory access address) due to the memory bandwidth compression mechanism. In this case, reading the original data corresponding to the first memory access address requires reading from the second memory access address. And usually in this case, the second memory access address also stores the original data corresponding to the second memory access address, that is, the second memory access address stores the compressed data of the original data corresponding to the first and second memory access addresses (i.e., the compressed first data and the compressed second data).

[0178] (iii) In one possible implementation, the storage granularity of the LLC is a cache line; the memory controller is specifically used for:

[0179] If it is determined that the first memory access address belongs to the third type of address, then the memory access data stored in a portion of the first memory access address is read; the third type of address includes addresses whose address length is greater than the cache line and whose corresponding compressed data of the original data is stored in the portion of the memory access address.

[0180] Specifically, in the third type of case mentioned above, the memory access data is stored in a portion of the first memory access address. For example, case 5: Request to read 128B of data. If the data is compressed, then read the data in a portion of the first memory access address. In case 5 above, the original data corresponding to the first memory access address is actually stored in a portion of the first memory access address. That is, the original data corresponding to the first memory access address (i.e., the uncompressed first data) is compressed and stored in a portion of the address segment of the first memory access address. In this case, to read the original data in the first memory access address, it is only necessary to read the corresponding address in the first memory access address.

[0181] In this embodiment of the application, since it is based on the memory bandwidth compression mechanism, in some cases, the data actually stored in the first memory access address may not be the original data corresponding to that address, or in other words, the original data originally requested by the first memory access request is not stored in the first memory access address. Therefore, for the data requested by the first memory access request, it may be reading part or all of the data in the first memory access address, or it may be reading data in other addresses besides the first memory access address.

[0182] In one possible implementation, the apparatus further includes a cache above the LLC or a multi-level cache; the first memory access request further includes a third memory access address; the memory controller is further configured to: before reading memory access data from the memory based on the first memory access address, hit the data corresponding to the third memory access address from the LLC or the cache above the LLC or a multi-level cache.

[0183] Although some of the requested data is in the on-chip cache and some is in the off-chip memory, from the perspective of the memory controller, it is still a memory access request. If part of it is hit in the on-chip cache, it will be marked as a hit of 64B (i.e., the third memory access address), while the remaining missing data, i.e. the first memory access address, will continue to be searched.

[0184] In this embodiment of the application, when the processor (specifically, the processor core) initiates the first memory access request, in some possible cases, the first memory access request may contain an address that is longer than the first memory access address (i.e., an address that contains both the first memory access address and the third memory access address). However, since the data corresponding to the third memory access address has already been hit in L1, L2 or L3, it is necessary to search for the remaining data of the first memory access address in memory.

[0185] In one possible implementation, the apparatus further includes a cache above the LLC; the memory controller is further configured to: receive a second memory access request to write third data cached in the LLC to the cache above the LLC, and determine whether the third data is compressed data; the LLC is further configured to: if the third data is compressed, decompress the compressed third data and write the decompressed third data to the cache above the LLC; if the third data is uncompressed, write the uncompressed third data to the cache above the LLC.

[0186] In this embodiment, when it is necessary to request that data in LLC (such as L3) be written to the cache level above or above the previous level of LLC, the data needs to be read from LLC. Since LLC in this embodiment stores compressed data or uncompressed data compressed according to preset compression rules, it is necessary to first determine whether the data is compressed data. If it is compressed data, it needs to be decompressed before being written to the cache level above (because the CPU core ultimately needs to read the uncompressed raw data). If the data is uncompressed data, it is directly read and written to the cache level above, and then finally sent to the processor core.

[0187] In one possible implementation, the apparatus further includes a cache above the LLC; the memory controller is further configured to: receive a write-back request to cache the fourth data in the upper-level cache to the LLC; the LLC is further configured to: if the fourth data is compressible, compress the fourth data and cache the compressed fourth data to the LLC; if the fourth data is not compressible, cache the fourth data to the LLC.

[0188] In this embodiment, when data needs to be written (ejected, or replaced) from the parent cache to the LLC cache, it is necessary to first determine whether the data is compressible. If it is compressible, the data is compressed first and then cached in the LLC. If the data is incompressible, it is cached in an uncompressed state so that it can be directly stored in memory in either a compressed or uncompressed state later. That is, for a given piece of data, if it is compressible, it can be compressed in the LLC first, and when written to memory later, no further judgment or compression is needed; it can be written directly to memory in its compressed state. Conversely, if the data is incompressible, it is stored in the LLC in an uncompressed state, and when written to memory later, it can be written directly to memory in its uncompressed state without further judgment or compression.

[0189] The following describes an embodiment of a write request (i.e., writing data into memory):

[0190] In one possible implementation, the memory controller is further configured to: receive a third memory access request to write the fifth data cached in the LLC to the memory; the LLC is further configured to: if the fifth data is in a compressed state, write the compressed fifth data to the memory.

[0191] For example, if there is compressed data in L3, it can be directly transferred to memory; and in the reverse case, if DDR reads data from L3, it does not need to be recompressed, but can be read directly in compressed form and cached in L3.

[0192] In this embodiment, when it is necessary to write the data cached in the last-level cache LLC to memory, it can first be determined whether the data is compressed data. If it is compressed data, it is also written to memory while maintaining its original compressed state, thereby realizing the function of compressing in one place and storing in multiple places. This not only saves bandwidth between on-chip (i.e., cache) and off-chip (i.e. memory), but also eliminates the need for repeated compression. This is because the LLC and memory are configured with the same compression mechanism, or in other words, the compression mechanism of memory covers the compression mechanism of cache. Therefore, repeated compression is unnecessary, further improving the efficiency of compressed data storage.

[0193] In one possible implementation, the LLC is further configured to: if the fifth data is in an uncompressed state, compress the fifth data and write the compressed fifth data into the memory; or, if the fifth data is in an uncompressed state, write the compressed fifth data into the memory.

[0194] In this embodiment, when data cached in the last-level cache LLC needs to be written to memory, it can be first determined whether the data is compressed. If it is uncompressed, the uncompressed data can be compressed before being sent to memory for storage. This reduces the bandwidth within the on-chip system and the bandwidth between on-chip and off-chip transmission. For example, in some possible embodiments, when the data to be written to memory is cached in the LLC in an uncompressed state, it can be further determined whether the data can be compressed. If it can be compressed, it can be further compressed in the on-chip memory controller before being stored in memory. That is, there may be some cases where the data cannot be compressed in the LLC, but it may be compressed in the memory controller before being written to memory. Optionally, in another possible implementation, the uncompressed data can be directly written to memory. This is because when the fifth data is cached in the LLC, it may have already been determined whether it can be compressed or not. If it cannot be compressed, it may be due to other reasons. Therefore, there is no need to perform a further determination or compression here, thus improving the efficiency of storage to memory.

[0195] Compared to the prior art's write request process, the embodiments of this application differ mainly in the following ways: Firstly, the prior art's write request process does not have the concept of prefetch caching, because in the prior art, the concept of prefetch caching only applies to the read request process, not the write request process. However, in the embodiments of this application, the LLC (such as L3) can act as a prefetch cache for both the read and write processes.

[0196] From the perspective of the write process, in the prior art, L3 can only store uncompressed data. Therefore, uncompressed data can only be read from L3, compressed by the memory controller, and then written to DDR. However, in the embodiment of this application, the data is compressed in L3, or the compressed data in L3 is passed to DDR in a compressed state, which is beneficial to improve the bandwidth between on-chip internal paths and the bandwidth between on-chip and off-chip.

[0197] From a read process perspective, existing L3 caches directly read uncompressed data from DDR or prefetch cache. This means that existing L3 caches do not store compressed data; regardless of whether data is read from DDR or prefetch cache into L3, existing L3 caches only uncompressed data. However, in this application, L3 cache can not only be used as a prefetch cache but also store compressed data. Furthermore, by setting the compression format and granularity of data in L3 cache to be the same as that in memory, L3 cache can work in conjunction with DDR cache to store compressed data.

[0198] The following describes relevant embodiments for read-modify-write requests (i.e., first reading data from memory or cache, then modifying the data, and finally writing the modified data back to memory or cache):

[0199] In one possible implementation, the device further includes other LLCs; the memory controller is further configured to: receive a request to read, modify, or write sixth data in the LLC; if the sixth data meets a preset condition, determine whether seventh data is in the LLC or the other LLC, wherein the seventh data is data whose physical address is adjacent to the sixth data in memory; if the seventh data is in a target LLC, obtain the seventh data from the target LLC; determine the compression state of the sixth data and the seventh data in the memory based on the compression state of the seventh data; and write the sixth data and the seventh data into the memory based on the determined compression state.

[0200] In Read-Write-Modify (RWM), when the processor writes data to memory, if the data length is less than the basic compression length, it needs to refer to the remaining data to determine the compression state of the data to be written to memory. This introduces additional memory read operations. For example, when the processor initiates a request to read-write-modify 64KB of data (such as the first data) to memory, and the basic compression length of the data in memory is to compress 128KB of data into 64KB, that is, the first data was originally compressed together with the second data in memory to become the memory access data (i.e., the compressed 64KB). In other words, two 64KB (total 128KB) are compressed into 64KB. When the processor needs to read-write-modify 64KB of the first data, it needs to first read the memory access data (i.e., the compressed first data + the second data), then modify it, and then rewrite it back into memory to complete the read-write-modify process. In this read-modify-write process, the processor originally only needed to read, modify, and write the first data. However, since the first data is compressed and stored together with the second data in memory, the second data, which wouldn't normally need to be read and modified, needs to be read from memory and stored in the cache during the read-modify-write process. Alternatively, when reading, modifying, and writing data for a target unit in memory, if the data length is 64, which is less than the basic compression unit of 128KB, then additional data needs to be read because it's necessary to reference data in another unit adjacent to the target unit, thus introducing additional memory read operations.

[0201] Based on the above, in this embodiment of the application, when the memory access system receives a request to read, modify, and write a certain data (i.e., the sixth data) in the LLC to memory, it needs to first determine whether the sixth data meets the preset conditions. Optionally, it can determine whether the sixth data meets the preset conditions by querying relevant information, such as the compression state of the sixth data itself, and the length and position (e.g., high or low bits) of the address corresponding to the sixth data. When it is determined based on the above relevant information that the length of the original address corresponding to the sixth data is less than or equal to the minimum unit of compressed storage (e.g., 64B), such as the sixth data being 64B of uncompressed data or 32B of compressed data, in some cases, whether the sixth data is read and modified in a compressed state or in an uncompressed state, and the address to which the sixth data is written after reading and modifying, may depend on the data (i.e., the seventh data) that is physically adjacent to it in memory. For example, if the sixth data is the high 64B of 128B aligned data, after compression, it may need to be stored together with the low 64B of the seventh data in the physical address of the seventh data. If the seventh data is incompressible, then the sixth data is also incompressible. In other words, it is necessary to refer to whether the seventh data associated with the sixth data can be compressed. For another example, if the sixth data is the low and high 64B of 128B aligned data, and it is determined that it is currently incompressible, but the address written back in the uncompressed state has already stored the compressed seventh data (the original high 64B data), then if the seventh data and its compression status are not obtained first, the sixth data cannot be written back in the uncompressed state. In other words, in this case, it is necessary to refer to the compression status and storage address of the seventh data associated with the sixth data. However, if the seventh data is stored in memory, the data needs to be read from memory, which not only increases the on-chip and off-chip bandwidth but also reduces the efficiency of data storage. Therefore, in this embodiment, the eighth data is preferentially searched in other LLCs in the processing device. The reason is that in the processing device of this embodiment, the last level cache and memory corresponding to different processor cores are interconnected and shared. Therefore, the seventh data may be cached in other LLCs. If the seventh data can be obtained from other LLCs, the additional memory bandwidth overhead caused by read-write can be reduced, and the read-write efficiency can be improved.

[0202] In one possible implementation, the memory controller includes a first compression module and a first decompression module; the LLC includes a second compression module and a second decompression module; the first compression module is used to compress uncompressed data stored in the memory that needs to be compressed; the second decompression module is used to decompress compressed data retrieved from the memory that needs to be decompressed; the second compression module is used to compress uncompressed data cached in the LLC that needs to be compressed; the second decompression module is used to decompress compressed data retrieved from the LLC that needs to be decompressed. In this embodiment, both the memory controller and the LLC may include corresponding compression and decompression modules, which can be used to compress or decompress related data under different processes, different memory access stages (e.g., reading data, writing data, read-modify-write data), or different compression granularity requirements.

[0203] It should be noted that the specific compression rules for compressed data stored in the cache or memory in this application embodiment can be set differently according to different application scenarios. For example, the compression method, compression algorithm, compression granularity and storage address of the compressed data can all be different according to different application requirements. The compression rules between LLC and memory can be exactly the same or not exactly the same. This application embodiment does not make specific limitations on this.

[0204] In one possible implementation, the first compression module and the second compression module use the same preset compression rules to compress the data.

[0205] In this embodiment, the compression modules in the memory controller and LLC use the same compression algorithm (i.e., compression mechanism) to compress the data. Correspondingly, the decompression modules in the memory controller and LLC also use the same decompression algorithm (i.e., the same decompression mechanism) to decompress the data. Optionally, the preset compression rules in the memory controller may include, but are not limited to, the preset compression rules in the LLC. That is, the compression and decompression modules in the memory controller may have more possible compression methods and granularities, as well as corresponding decompression methods and granularities, than the LLC.

[0206] For example, please see Figure 3A , Figure 3A This is a schematic diagram illustrating a physical memory space partitioning method provided in this application embodiment. Since physical memory is typically managed in units of pages, and virtual memory is ultimately mapped onto physical memory, there is also a corresponding concept of virtual pages in the virtual memory space. Memory mapping is usually performed in units of pages. The contiguous virtual memory seen by a process (system or application process) may not be contiguous in physical memory; for example, on the upper... Figure 3A In process 1, virtual pages 2 and 3 are contiguous in process 1's virtual memory space, but their mapped physical memory pages are not contiguous (corresponding to physical pages 1 and 3, respectively). Similarly, in process 2, virtual page 5 is mapped to physical page 5, and virtual page 6 is mapped to physical page 7. Physical pages 1, 2, and 3 in the physical memory space are the memory currently used by process 1, while physical pages 5 and 7 are the memory currently used by process 2. These complex and specific memory mapping details can be managed by the memory management subsystem running on the processor or memory controller.

[0207] For example, please see Figure 3B , Figure 3B This application provides a schematic diagram of physical page address partitioning, for example, in the embodiment of the present application. Figure 3B In a System-on-a-Chip (SoC) 10, when the cache line granularity is 64 bytes and a physical page size is 4KB, a physical page can be divided into 64 memory units of 64 bytes each. Since 1KB = 1024B, 4KB / 64B = 64 memory units, meaning a 4KB memory region comprises 64 memory units. The cache line is the smallest unit of data transfer between the CPU and main memory, representing the smallest memory access granularity. For example, with a cache line size of 64 bytes, the CPU will continuously fetch 64 bytes of data from main memory during data transfer.

[0208] For example, please see Figure 3C , Figure 3C This application provides a schematic diagram of 128B aligned high 64B and low 64B. Figure 3C For example, a 4K memory page may include 32 memory units with cache lines as the granularity, each memory unit being 64 bytes in size. The high 64 bits and low 64 bits of 128 bytes of data can be stored between two adjacent memory units. It is understood that other alignment sizes can also be used as the compression granularity in this application, such as compressing 256 bytes of data to 64 bytes, or compressing 256 bytes of data to 128 bytes, etc. This application does not specifically limit this aspect.

[0209] For example, based on the above diagram illustrating the partitioning of physical addresses, in one possible embodiment, please refer to... Figure 4A , Figure 4A This application provides a schematic diagram illustrating the mapping relationship between data and addresses before and after compression, as shown in the embodiments of this application. Figure 4AIn this embodiment, it is assumed that the first memory access address and the second memory access address are two adjacent 64-bit addresses aligned to 128-bit, where the first memory access address is the high 64-bit address and the second memory access address is the low 64-bit address. The original data corresponding to the first memory access address is the first data (i.e., if it is not compressed, the first data should be stored at the first memory access address), and the original data corresponding to the second memory access address is the second data (i.e., if it is not compressed, the second data should be stored at the second memory access address). When the first data and the second data are compressed based on memory bandwidth compression technology, and assuming that the 128-bit data is compressed and stored in the low 64-bit address, it becomes the first compressed data and the second compressed data stored in the second memory access address. For example, the high 64 bits and low 64 bits of data are compressed into high 32 bits and low 32 bits of data respectively according to a preset compression rule. Both the compressed 32 bits of high data and low data are stored in the second memory access address (the address length of the low 64 bits). Therefore, the first memory access address is freed up, and the second memory access address stores the first and second data that would have been stored in the first and second memory access addresses respectively. Thus, when the processor requests to read from the first memory access address (i.e., the original purpose was to request the first data), it actually needs to read from the second memory access address. Due to the memory access granularity, assuming the minimum granularity is 64 bits, the memory access data read in this request includes both the first and second compressed data, i.e., the compressed high 32 bits of data + the low 32 bits of data. In this case, the extra data read is the second compressed data.

[0210] In another possible embodiment, see Figure 4B , Figure 4B This application provides another schematic diagram illustrating the mapping relationship between data and addresses before and after compression, as shown in the embodiments of this application. Figure 4BIn this embodiment, it is assumed that the first memory access address and the second memory access address are two adjacent 64-bit addresses aligned to 128-bit, where the first memory access address is the lower 64-bit address and the second memory access address is the higher 64-bit address. The original data corresponding to the first memory access address is the first data (i.e., if it is not compressed, the first data should be stored at the first memory access address), and the original data corresponding to the second memory access address is the second data (i.e., if it is not compressed, the second data should be stored at the second memory access address). When the first data and the second data are compressed based on memory bandwidth compression technology, and assuming that the 128-bit data is compressed and stored in the lower 64-bit address, it becomes the first compressed data and the second compressed data stored in the first memory access address. For example, the high 64 bits and low 64 bits of data are compressed into high 32 bits and low 32 bits of data respectively according to a preset compression rule. Both the compressed 32 bits of high data and low 32 bits of low data are stored at the first memory access address (64-bit address length). Therefore, the second memory access address is left empty, while the first memory access address stores the first and second data that would normally be stored at the first and second memory access addresses respectively. Thus, when the processor requests to read from the first memory access address (i.e., the original purpose was to request the first data), it reads from the first memory access address. However, due to the memory access granularity, assuming the smallest granularity is 64 bits, the memory access data read in this request includes both the first and second compressed data, i.e., the compressed high 32 bits of data + the low 32 bits of data. In this case, the extra data read is the second compressed data.

[0211] In yet another possible embodiment, see [link to relevant documentation]. Figure 4C , Figure 4C This application provides another schematic diagram illustrating the mapping relationship between data and addresses before and after compression, as shown in the embodiments of this application. Figure 4CIn this embodiment, it is assumed that the first memory access address is a 128B aligned address. The 128B of the first memory access address can be divided into a high 64B bit and a low 64B bit, and the original data corresponding to the first memory access address is the first data (i.e., if it is not compressed, the first data should be stored in the first memory access address). When the first data is compressed based on memory bandwidth compression technology (either by directly compressing 128B to 64B, or by compressing two 64Bs to 32B respectively), and assuming that the 128B data is compressed and stored in the low 64B address, then the first compressed data (i.e., the compressed first data) is stored in the low 64B position of the first memory access address. For example, the high 64 bits and low 64 bits of data are compressed into high 32 bits and low 32 bits of data respectively according to a preset compression rule. The compressed 32 bits of high and low data are then stored in the low 64 bits of the first memory access address (64 bits in address length). Therefore, the high 64 bits of the first memory access address are left empty, while the low 64 bits of the first memory access address store the first data that would have been stored in the high and low 64 bits of the first memory access address. Thus, when the processor requests to read the first memory access address, it reads the first compressed data from the low 64 bits of the first memory access address, i.e., the compressed high 32 bits plus the low 32 bits of data. In this case, it is equivalent to not reading any extra data.

[0212] In yet another possible embodiment, see [link to relevant documentation]. Figure 4D , Figure 4D This application provides another schematic diagram illustrating the mapping relationship between data and addresses before and after compression, as shown in the embodiments of this application. Figure 4D In this embodiment, it is assumed that the first memory access address is a non-128B aligned address, which spans the lower 64B-01 and higher 64B-02 of two 128B aligned addresses. After these two data are compressed using memory bandwidth compression technology, and assuming that the 128B data is compressed and stored in the lower 64B address (for example, the higher 64B-01 bits and the lower 64B-01 bits of data are compressed and stored in the lower 64B-01 address, while the higher 64B-02 bits and the lower 64B-02 bits of data are not compressed and remain in their original locations), the first memory access address contains the original higher 64B-01 bits of data, the lower 64B-01 bits of data, and the higher 64B-02 bits of data, and both the original higher 64B-01 bits of data and the lower 64B-01 bits of data are compressed data. Therefore, when the processor requests to read the first memory access address, three pieces of data will be read from that address: the compressed high 32B-01 bits, the low 32B-01 bits, and the high 64B-02 bits. In this case, the extra data read is equivalent to the high 32B-01 bits.

[0213] The following example illustrates the memory access process for reading data, using a processor issuing a DDR memory access request that supports both 64B and 128B memory lengths. Please refer to [link to relevant documentation]. Figure 5A and Figure 5B , Figure 5A This application provides a flowchart illustrating the processing of a 128B read request in an embodiment. Figure 5B This is a flowchart illustrating a 64B read request processing method provided in this application embodiment. The following describes the specific process for processing 128B and 64B read requests in this application embodiment, using 128B or 64B granularity as examples:

[0214] The following describes the specific process of processing 128B and 64B read requests in this embodiment of the application, taking 128B or 64B granularity as examples:

[0215] Scenario 1: 128B Read Process

[0216] The processor issues a 128B DDR request, and after the memory controller 105 receives the 128B read request, it first checks whether a complete 128B of data exists in each cache level. If it exists in L1, it reads it directly from L1; if it exists in L2, it copies it from L2 to L1 before reading it. Assuming that neither L1 nor L2 is found, the specific scenarios could include the following:

[0217] (1) No hit in L1 → No hit in L2 → Complete 128B data in L3 → Read directly from L3;

[0218] (2) No hit in L1 → No hit in L2 → Partial 64B data in L3 → The remaining 64B data is requested from DDR (at this time, it is also necessary to first determine the compression status of the data so as to read it from the corresponding address);

[0219] (3) L1 miss → L2 miss → L3 miss → Determine the compression status of the data to be read → If it is compressed data → Access the lower 64B address in DDR according to the 64B length;

[0220] (4) L1 miss → L2 miss → L3 miss → If it is uncompressed data → access the complete 128B address in DDR according to the length of 128B.

[0221] Scenario 2: 64B Read Process

[0222] When the processor issues a 64-byte DDR request, and the memory controller 105 receives the request, it first checks if the complete 64-byte data exists in any of the cache levels. If it exists in L1, it reads the data directly from L1. If it exists in L2, it copies the data from L2 to L1 before reading it. If neither L1 nor L2 caches contain the data, the following scenarios may occur:

[0223] (1) Miss in L1 → Miss in L2 → 64B data is in L3 → Read directly;

[0224] (2) Miss in L1 → Miss in L2 → Miss in L3 (query missing) and the memory access address is the lower 64B → directly access the address of the lower 64B in DDR → if it is compressed data → store the extra data in L3;

[0225] (3) L1 miss → L2 miss → L3 miss (i.e., query missing) and the memory access address is the high 64B of the read → determine the compression status of the data to be read → if it is compressed data → access the low 64B address in DDR according to the 64B length → if it is not compressed data → access the high 64B address in DDR according to the 64B length.

[0226] The following example illustrates the memory access process for writing data, using a processor issuing a DDR memory access request that supports both 64B and 128B memory lengths. Please refer to [link to relevant documentation]. Figure 5C and Figure 5D , Figure 5C This application provides a flowchart illustrating the process of handling a 128B write request. Figure 5D This is a flowchart illustrating a 64B write request processing method provided in this application embodiment. The following describes the specific process for processing 128B and 64B write requests in this application embodiment, using either a 128B or 64B granularity as examples:

[0227] Scenario 1: Writing the process using 128B

[0228] When the processor issues a 128B DDR request and the memory controller 105 receives the 128B write request, the specific scenarios can include the following:

[0229] (1) If the data to be written is compressed data cached in L3, then the compressed data is directly written from L3 in its original compressed format to DDR.

[0230] (2) The data to be written is uncompressed data cached in L3 → Determine whether the data to be written is compressible → If it is compressible, compress it and write it to the lower 64B address in DDR → If it is not compressible, write it to the corresponding 128B address in DDR in an uncompressed state.

[0231] Scenario 2: Writing the process in 64B

[0232] When the processor issues a 64-byte DDR request, and the memory controller 105 receives the 64-byte write or read / modify request, the specific scenarios can include the following:

[0233] (1) No hit in L1 → No hit in L2 → Hit in L3 → If the preset conditions are met, check if the other 64B is on the chip → If it is on the chip, get the data from the other L3 on the chip → Process according to write 128B.

[0234] (2) No hit in L1 → No hit in L2 → Hit in L3 → Check if the other 64B is on the chip → If it is not on the chip and the DDR bandwidth is relatively idle (i.e., the bandwidth is currently used less), then obtain the other 64B data from DDR → Process as writing 128B.

[0235] (3) Miss in L1 → Miss in L2 → Hit in L3 → Check if the other 64B is on the chip → If it is not on the chip and the DDR bandwidth is in a relatively tight state (i.e., the bandwidth is currently being used a lot), then directly write to the position corresponding to the uncompressed lower 64B and update the compression flag.

[0236] It should be noted that in the description of the above embodiments, the numerical serial numbers (1), (2), (3), etc. do not represent a strict time execution order or sequential order. That is, the serial numbers do not limit the execution order of the process or the order in which the states occur. Furthermore, the embodiments in the different scenarios described above do not constitute a limitation. The different embodiments described above can be executed independently of each other or in combination with each other. These will not be described in detail here.

[0237] Please see Figure 6 , Figure 6 This is a flowchart illustrating a storage management method provided in an embodiment of this application. This storage management method can be applied to processing devices, System-on-a-Chip (SoC), off-chip memory management systems, memory access systems, electronic devices including SoCs, or memory management modules within electronic devices. The electronic device includes a processor core, a last-level cache LLC, and memory. The memory stores compressed data and / or uncompressed data compressed according to a preset compression rule. The method may include the following steps S601-S603, wherein...

[0238] Step S601: Receive a first memory access request sent by the processor core for reading the first data, wherein the first memory access request carries a first memory access address;

[0239] Step S602: Read memory access data from the memory coupled to the processor core based on the first memory access address;

[0240] Step S603: If the memory access data includes the first data and the compressed second data, then in response to the first memory access request, the first data is sent to the processor core, and the compressed second data is cached in the LLC.

[0241] In one possible implementation, the memory access data further includes a compression flag indicating whether the second data is in a compressed state; the method further includes caching the compression flag in the LLC.

[0242] In one possible implementation, if the first data is in a compressed state, sending the first data to the processor core includes: in response to the first memory access request, sending the compressed first data to the LLC; receiving and caching the compressed first data through the LLC, reading the cached compressed first data and decompressing it before sending it to the processor core; or, decompressing the received compressed first data through the LLC before sending it to the processor core; wherein the compressed first data is obtained by compressing part or all of the original data corresponding to the first memory access address, and the compressed second data is obtained by compressing part or all of the original data corresponding to the second memory access address in the memory.

[0243] In one possible implementation, if the memory access data includes the first data and the first data is in a compressed state, the method further includes: in response to the first memory access request, sending the compressed first data to the LLC; receiving and caching the compressed first data through the LLC, reading the cached compressed first data and decompressing it before sending it to the processor core; or, decompressing the received compressed first data through the LLC before sending it to the processor core.

[0244] In one possible implementation, if the memory access data includes the first data, and the first data is in an uncompressed state; the method further includes: in response to the first memory access request, sending the uncompressed first data to the LLC; receiving and caching the uncompressed first data through the LLC and sending it to the processor core; or, sending the received uncompressed first data to the processor core through the LLC.

[0245] In one possible implementation, if the memory access data includes the first data, and the first data is in an uncompressed state; the method further includes: in response to the first memory access request, sending the uncompressed first data to the LLC; if the uncompressed first data is compressible, then compressing and caching the received uncompressed first data through the LLC, and sending the uncompressed first data to the processor core; if the uncompressed first data is incompressible, then receiving and caching the uncompressed first data through the LLC, and sending the uncompressed first data to the processor core.

[0246] In one possible implementation, reading memory access data from memory coupled to the processor core based on the first memory access address includes: determining data compression information corresponding to the first memory access address based on a pre-stored mapping relationship; the mapping relationship includes a mapping relationship between address information and data compression information; and reading the memory access data from the memory based on the first memory access address and the corresponding data compression information.

[0247] In one possible implementation, the storage granularity of the LLC is a cache line; the step of reading the memory access data from the memory based on the first memory access address and the corresponding data compression information includes: if it is determined that the first memory access address belongs to a first type of address, then reading the memory access data stored in the first memory access address; the first type of address includes addresses whose address length is less than or equal to the cache line and which store data, or addresses whose address length is greater than the cache line and which store original data; or, if it is determined that the first memory access address belongs to a second type of address, then reading the memory access data stored in the second memory access address; the second type includes addresses whose address length is less than or equal to the cache line and whose corresponding compressed data is stored in the second memory access address; or, if it is determined that the first memory access address belongs to a third type of address, then reading the memory access data stored in a portion of the memory access addresses in the first memory access address; the third type of address includes addresses whose address length is greater than the cache line and whose corresponding compressed data is stored in the portion of the memory access addresses.

[0248] In one possible implementation, the first memory access request further includes a third memory access address; the method further includes: before reading memory access data from the memory based on the first memory access address, hitting the data corresponding to the third memory access address from the LLC or the cache of the LLC at one or more levels above it.

[0249] In one possible implementation, the method further includes: receiving a second memory access request to write third data cached in the LLC to the upper-level cache; determining whether the third data is compressed data; if the third data is compressed, decompressing the compressed third data through the LLC and writing the decompressed third data to the upper-level cache; if the third data is uncompressed, writing the uncompressed third data to the upper-level cache through the LLC.

[0250] In one possible implementation, the method further includes: receiving a write-back request to cache the fourth data in the previous level cache to the LLC; if the fourth data is compressible, compressing the fourth data through the LLC and caching the compressed fourth data to the LLC; if the fourth data is not compressible, caching the fourth data to the LLC through the LLC.

[0251] In one possible implementation, the method further includes: receiving a third memory access request to write the fifth data cached in the LLC to the memory; if the fifth data is in a compressed state, then writing the compressed fifth data to the memory through the LLC.

[0252] In one possible implementation, the method further includes: if the fifth data is in an uncompressed state, then compressing the fifth data through the LLC and writing the compressed fifth data into the memory; or, if the fifth data is in an uncompressed state, then writing the compressed fifth data into the memory through the LLC.

[0253] In one possible implementation, the method further includes: receiving a request to read, modify, and write sixth data in the LLC; if the sixth data meets a preset condition, determining whether seventh data is in the LLC or another LLC, wherein the seventh data is data whose physical address is adjacent to the sixth data in memory; if the seventh data is in a target LLC, obtaining the seventh data from the target LLC; determining the compression state of the sixth data and the seventh data in the memory based on the compression state of the seventh data; and writing the sixth data and the seventh data into the memory based on the determined compression state.

[0254] It should be noted that the specific process of the storage management method described in the embodiments of this application can be found in the above. Figures 2A-4D The relevant descriptions in the application embodiments described herein will not be repeated here.

[0255] This application also provides a computer-readable storage medium, wherein the computer-readable storage medium may store a program, which, when executed by an electronic device, includes some or all of the steps described in any of the above method embodiments.

[0256] This application also provides a computer program that includes instructions that, when executed by an electronic device, enable the electronic device to perform some or all of the steps of any storage management method.

[0257] In the above embodiments, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0258] It should be noted that, for the sake of simplicity, the foregoing method embodiments are all described as a series of actions. However, those skilled in the art should understand that this application is not limited to the described order of actions, as some steps may be performed in other orders or simultaneously according to this application. Furthermore, those skilled in the art should also understand that the embodiments described in the specification are preferred embodiments, and the actions and modules involved are not necessarily essential to this application.

[0259] In the several embodiments provided in this application, it should be understood that the disclosed apparatus can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of the units described above is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between devices or units may be electrical or other forms.

[0260] The units described above as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0261] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0262] If the integrated units described above are implemented as software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which can be a personal computer, server, or network device, specifically a processor in the computer device) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium may include various media capable of storing program code, such as a USB flash drive, portable hard drive, magnetic disk, optical disk, read-only memory (ROM), or random access memory (RAM).

[0263] The above-described embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application.

Claims

1. A processing apparatus, characterized in that, include: Processor core, last-level cache LLC, and memory controller; The memory controller is used for: Receive a first memory access request sent by the processor core for reading first data, wherein the first memory access request carries a first memory access address; Memory access data is read from the memory coupled to the processing device based on the first memory access address; If the memory access data includes the first data and the compressed second data, then in response to the first memory access request, the first data is sent to the processor core through the LLC, and the compressed second data is cached in the LLC.

2. The apparatus according to claim 1, characterized in that, The memory access data also includes a compression flag indicating whether the second data is in a compressed state; the memory controller is further configured to cache the compression flag in the LLC.

3. The apparatus according to claim 1 or 2, characterized in that, If the first data is in a compressed state; The memory controller is specifically configured to: in response to the first memory access request, send the compressed first data to the LLC; The LLC is configured to receive and cache the first data in the compressed state, read the cached first data in the compressed state, decompress it, and then send it to the processor core; or, the LLC is configured to decompress the received first data in the compressed state and then send it to the processor core. Wherein, the first data in the compressed state is obtained by compressing part or all of the original data corresponding to the first memory access address, and the second data in the compressed state is obtained by compressing part or all of the original data corresponding to the second memory access address in the memory.

4. The apparatus according to any one of claims 1-3, characterized in that, If the memory access data includes the first data and the first data is in a compressed state; The memory controller is further configured to: in response to the first memory access request, send the compressed first data to the LLC; The LLC is used to receive and cache the first data in the compressed state, read the cached first data in the compressed state, decompress it, and send it to the processor core; or, The LLC is used to decompress the first data received in the compressed state and then send it to the processor core.

5. The apparatus according to any one of claims 1-4, characterized in that, If the memory access data includes the first data, and the first data is in an uncompressed state; The memory controller is further configured to: in response to the first memory access request, send the uncompressed first data to the LLC; The LLC is used to receive and cache the first data in the uncompressed state and send it to the processor core; Alternatively, the LLC is used to send the received uncompressed first data to the processor core.

6. The apparatus according to any one of claims 1-4, characterized in that, If the memory access data includes the first data, and the first data is in an uncompressed state; The memory controller is further configured to: in response to the first memory access request, send the uncompressed first data to the LLC; The LLC is used for: If the first data in the uncompressed state is compressible, then the received first data in the uncompressed state is compressed and cached, and the uncompressed first data is sent to the processor core; If the first data in the uncompressed state is incompressible, then the first data in the uncompressed state is received and cached, and the first data in the uncompressed state is sent to the processor core.

7. The apparatus according to any one of claims 1-6, characterized in that, The memory controller stores a mapping relationship between address information and data compression information; the memory controller is specifically used for: Based on the mapping relationship, determine the data compression information corresponding to the first memory access address; Based on the first memory access address and the corresponding data compression information, the memory access data is read from the memory.

8. The apparatus according to claim 7, characterized in that, The LLC's storage granularity is a cache line; the memory controller is specifically used for: If it is determined that the first memory access address belongs to the first type of address, then the memory access data stored in the first memory access address is read; the first type of address includes addresses whose address length is less than or equal to the cache line and which store data, or addresses whose address length is greater than the cache line and which store original data; or, If it is determined that the first memory access address belongs to the second type of address, then the memory access data stored in the second memory access address is read; the second type includes addresses whose address length is less than or equal to the cache line, and whose corresponding compressed data of the original data is stored in the second memory access address; or, If it is determined that the first memory access address belongs to the third type of address, then the memory access data stored in a portion of the first memory access address is read; the third type of address includes addresses whose address length is greater than the cache line and whose corresponding compressed data of the original data is stored in the portion of the memory access address.

9. The apparatus according to any one of claims 1-8, characterized in that, The device further includes a cache level above the LLC or a multi-level cache; the first memory access request further includes a third memory access address; the memory controller is further configured to: Before reading memory access data from the memory based on the first memory access address, the data corresponding to the third memory access address is hit from the LLC or the cache of the LLC at the next higher level or multiple levels.

10. The apparatus according to any one of claims 1-9, characterized in that, The device further includes a cache level above the LLC; the memory controller is also configured to: Receive a second memory access request to write the third data cached in the LLC to the upper-level cache, and determine whether the third data is compressed data; The LLC is also used for: If the third data is in a compressed state, then the compressed third data is decompressed and the decompressed third data is written to the previous level cache; If the third data is in an uncompressed state, then the uncompressed third data is written to the previous level cache.

11. The apparatus according to any one of claims 1-10, characterized in that, The device further includes a cache level above the LLC; the memory controller is also configured to: Receive a write-back request to cache the fourth data in the previous level cache to the LLC; The LLC is also used for: If the fourth data is compressible, then the fourth data is compressed and the compressed fourth data is cached in the LLC; If the fourth data is not compressible, then the fourth data is cached in the LLC.

12. The apparatus according to any one of claims 1-11, characterized in that, The memory controller is further configured to: Receive a third memory access request to write the fifth data cached in the LLC to the memory; The LLC is further configured to: if the fifth data is in a compressed state, write the compressed fifth data into the memory.

13. The apparatus according to claim 12, characterized in that, The LLC is also used for: If the fifth data is in an uncompressed state, then the fifth data is compressed and the compressed fifth data is written into the memory; or, if the fifth data is in an uncompressed state, then the compressed fifth data is written into the memory.

14. The apparatus according to any one of claims 1-13, characterized in that, The device also includes other LLCs; the memory controller is further configured to: Receive a request to read, modify, or write the sixth data in the LLC; If the sixth data satisfies the preset conditions, then it is determined whether the seventh data is in the LLC or the other LLC, and the seventh data is the data whose physical address is adjacent to the sixth data in memory; If the seventh data is in the target LLC, then the seventh data is obtained from the target LLC; Based on the compression state of the seventh data, the compression state of the sixth data and the seventh data written into the memory is determined; The sixth and seventh data are written to the memory based on the determined compression state.

15. The apparatus according to any one of claims 1-14, characterized in that, The memory controller includes a first compression module and a first decompression module; the LLC includes a second compression module and a second decompression module. The first compression module is used to compress uncompressed data stored in the memory that needs to be compressed; the second decompression module is used to decompress compressed data retrieved from the memory that needs to be decompressed. The second compression module is used to compress uncompressed data cached in LLC that needs to be compressed; the second decompression module is used to decompress compressed data retrieved from LLC that needs to be decompressed.

16. The apparatus according to claim 15, characterized in that, The first compression module and the second compression module use the same preset compression rules to compress the data.

17. A storage management method, characterized in that, include: Receive a first memory access request sent by the processor core for reading first data, wherein the first memory access request carries a first memory access address; Memory access data is read from the memory coupled to the processor core based on the first memory access address; If the memory access data includes the first data and the compressed second data, then in response to the first memory access request, the first data is sent to the processor core, and the compressed second data is cached in the LLC.

18. The method according to claim 17, characterized in that, The memory access data also includes a compression flag indicating whether the second data is in a compressed state; the method further includes caching the compression flag in the LLC.

19. The method according to claim 17 or 18, characterized in that, If the first data is in a compressed state, sending the first data to the processor core includes: In response to the first memory access request, the compressed first data is sent to the LLC; The LLC receives and caches the compressed first data, reads the cached compressed first data, decompresses it, and sends it to the processor core; or, the LLC decompresses the received compressed first data and sends it to the processor core. Wherein, the first data in the compressed state is obtained by compressing part or all of the original data corresponding to the first memory access address, and the second data in the compressed state is obtained by compressing part or all of the original data corresponding to the second memory access address in the memory.

20. The method according to any one of claims 17-19, characterized in that, If the memory access data includes the first data and the first data is in a compressed state; the method further includes: In response to the first memory access request, the compressed first data is sent to the LLC; The LLC receives and caches the first compressed data, reads the cached first compressed data, decompresses it, and sends it to the processor core; or, the LLC decompresses the received first compressed data and sends it to the processor core.

21. The method according to any one of claims 17-20, characterized in that, If the memory access data includes the first data, and the first data is in an uncompressed state; the method further includes: In response to the first memory access request, the uncompressed first data is sent to the LLC; The LLC receives and buffers the uncompressed first data and sends it to the processor core; or, the LLC sends the received uncompressed first data to the processor core.

22. The method according to any one of claims 17-20, characterized in that, If the memory access data includes the first data, and the first data is in an uncompressed state; the method further includes: In response to the first memory access request, the uncompressed first data is sent to the LLC; If the first data in the uncompressed state is compressible, then the received first data in the uncompressed state is compressed and cached by the LLC, and the uncompressed first data is sent to the processor core; If the first data in the uncompressed state is incompressible, then the first data in the uncompressed state is received and cached by the LLC, and the first data in the uncompressed state is sent to the processor core.

23. The method according to any one of claims 17-22, characterized in that, The step of reading memory access data from memory coupled to the processor core based on the first memory access address includes: The data compression information corresponding to the first memory access address is determined based on a pre-stored mapping relationship; the mapping relationship includes a mapping relationship between address information and data compression information. Based on the first memory access address and the corresponding data compression information, the memory access data is read from the memory.

24. The method according to claim 23, characterized in that, The LLC's storage granularity is a cache line; the step of reading the accessed data from the memory based on the first access address and the corresponding data compression information includes: If it is determined that the first memory access address belongs to the first type of address, then the memory access data stored in the first memory access address is read; the first type of address includes addresses whose address length is less than or equal to the cache line and which store data, or addresses whose address length is greater than the cache line and which store original data; or, If it is determined that the first memory access address belongs to the second type of address, then the memory access data stored in the second memory access address is read; the second type includes addresses where the address length is less than or equal to the cache line, and the compressed data of the corresponding original data is stored in the second memory access address; or, If it is determined that the first memory access address belongs to the third type of address, then the memory access data stored in a portion of the first memory access address is read; the third type of address includes addresses whose address length is greater than the cache line and whose corresponding compressed data of the original data is stored in the portion of the memory access address.

25. The method according to any one of claims 17-24, characterized in that, The method further includes: Receive a second memory access request to write the third data cached in the LLC to the upper-level cache, and determine whether the third data is compressed data; If the third data is in a compressed state, then the compressed third data is decompressed by the LLC and the decompressed third data is written to the previous level cache; If the third data is in an uncompressed state, then the uncompressed third data is written to the previous level cache through the LLC.

26. The method according to any one of claims 17-25, characterized in that, The method further includes: Receive a write-back request to cache the fourth data in the previous level cache to the LLC; If the fourth data is compressible, then the fourth data is compressed through the LLC, and the compressed fourth data is cached in the LLC; If the fourth data is not compressible, then the fourth data is cached in the LLC.

27. The method according to any one of claims 17-26, characterized in that, The method further includes: Receive a third memory access request to write the fifth data cached in the LLC to the memory; If the fifth data is in a compressed state, then the compressed fifth data is written into the memory via the LLC.

28. The method according to claim 27, characterized in that, The method further includes: If the fifth data is in an uncompressed state, then the fifth data is compressed using the LLC and the compressed fifth data is written into the memory; or, if the fifth data is in an uncompressed state, then the compressed fifth data is written into the memory using the LLC.

29. The method according to any one of claims 17-28, characterized in that, The method further includes: Receive a request to read, modify, or write the sixth data in the LLC; If the sixth data satisfies the preset conditions, then it is determined whether the seventh data is in the LLC or the other LLC, and the seventh data is the data whose physical address is adjacent to the sixth data in memory; If the seventh data is in the target LLC, then the seventh data is obtained from the target LLC; Based on the compression state of the seventh data, the compression state of the sixth data and the seventh data written into the memory is determined; The sixth and seventh data are written to the memory based on the determined compression state.

30. An electronic device, characterized in that, include: The processing apparatus and the memory as described in any one of claims 1-16 above.

31. A computer-readable storage medium, characterized in that, The computer-readable medium is used to store program code that, when executed by an electronic device, implements the method described in any one of claims 17-29.

32. A computer program, characterized in that, The computer program includes instructions that, when executed by an electronic device, cause the electronic device to perform the method as described in any one of claims 17-29.

Images