Sharing the instruction cache footprint among multiple threads

Abstract

An aspect is provided for sharing an instruction cache footprint between multiple threads. A set / way pointer for an instruction cache line is derived from an address in a system memory associated with an instruction fetch from a memory page. The instruction cache line is determined to be shareable between a first thread and a second thread. An alias table entry is created indicating that another instruction cache line associated with the memory page is also shareable between the threads. Another instruction fetch is received from another thread requesting instructions from another address in a system memory associated with the memory page. A further set / way pointer to another instruction cache line is derived from the other system memory address. The other instruction cache line is determined to be shareable based on the alias table entry.

Description

[Technical Field]

[0001] The present disclosure relates generally to memory caches, and more particularly to systems and methods for sharing an instruction cache footprint among multiple processor threads. [Background technology]

[0002] Cache memory (or "cache") is a secondary memory system that temporarily stores frequently used instructions and data so that a computer's central processor can process them more quickly. Cache augments and acts as an extension of a computer's main memory. Cache typically holds newer, more frequently used copies of information and program code stored in main memory. Cache typically operates faster than system memory, reducing the time required to locate and provide cached data and instructions to the central processor.

[0003] In a multithreaded processing environment with an EA (effective address) cache, there is typically no way to determine which instruction cache lines (or ways within a set) can be shared across process boundaries. Furthermore, instruction cache lines (or ways within a set) are typically marked separately for each thread. Therefore, the instruction cache footprint typically cannot be shared between different processor threads in a multithreaded processor environment. Summary of the Invention

[0004] According to various embodiments of the present disclosure, a computing device, a non-transitory computer-readable storage medium, and a method for sharing an instruction cache footprint among multiple threads are provided.

[0005] Aspects of the present disclosure include sharing an instruction cache footprint among multiple threads of a multithreaded processor using instruction cache (e.g., L2) set / way pointers and an alias table. The alias table contains effective addresses (EAs) that represent memory regions (e.g., pages) identified as shared among multiple threads. The alias table also contains information for verifying whether the translation of an accessing thread matches the time of allocation.

[0006] An instruction fetch is received from a first thread requesting instructions from a system memory address associated with the memory page. A set / way pointer to an instruction cache line is derived from the system memory address. Another instruction fetch is received from a second thread requesting instructions from another system memory address associated with the memory page. Another set / way pointer to another instruction line is derived from the other system memory address. When it is detected that the set / way pointer and the other set / way pointer both point to the instruction cache line, it is determined that the instruction cache line is shareable between the first thread and the second thread.

[0007] In one aspect, determining the shareability of the instruction cache line includes accessing an other set / way pointer from a tracking table, the other set / way pointer being derived from caching instructions in the instruction cache line associated with the second thread. It is detected that both the set / way pointer and the other set / way pointer point to the instruction cache line. In another aspect, when the cache data is returned, a read-modify-write of the instruction cache directory is performed to locate the potentially shareable instruction cache line.

[0008] Upon determining the shareability of the instruction cache line, an alias table entry is entered into the alias table indicating that other instruction cache lines associated with the memory page are also shareable between the first thread and the second thread. Thereafter, a further instruction fetch is received from the second thread. The further instruction fetch requests further instructions from an address in a further system memory associated with the memory page. A further set / way pointer to the further instruction cache line is derived from the address in the further system memory. The further instruction cache line caches instructions fetched by the first thread from the address in the further system memory. Based on the alias table entry, it is determined that the further instruction cache line is shareable with the second thread.

[0009] The instruction cache line and the further instruction cache line may then be returned to either the first thread or the second thread in response to a subsequent instruction fetch for an instruction from the first thread or the second thread.

[0010] These and other features will become apparent from the following detailed description of illustrative embodiments thereof, which is to be read in connection with the accompanying drawings.

[0011] Preferred embodiments of the present invention will now be described, by way of example only, with reference to the following drawings: [Brief explanation of the drawings]

[0012] [Figure 1A] 1 illustrates an exemplary computer architecture that facilitates sharing an instruction cache footprint among multiple threads in accordance with an exemplary embodiment. [Figure 1B] 1 illustrates an exemplary computer architecture that facilitates sharing an instruction cache footprint among multiple threads in accordance with an exemplary embodiment. [Figure 2A]1 illustrates a flowchart of an exemplary method for sharing an instruction cache footprint among multiple threads in accordance with an exemplary embodiment. [Figure 2B] 1 illustrates a flowchart of an exemplary method for sharing an instruction cache footprint among multiple threads in accordance with an exemplary embodiment. [Figure 3] 1 illustrates a computer hardware platform specifically configured in accordance with an exemplary embodiment. [Figure 4] 1 illustrates an example of a memory architecture consistent with an exemplary embodiment. DETAILED DESCRIPTION OF THE INVENTION

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

[0014] The present disclosure generally relates to a computing device, a non-transitory computer-readable storage medium, and a method for sharing instruction cache lines among multiple threads. In one aspect, multiple (e.g., four) threads take turns fetching instructions from a common instruction cache (or "iCache"). The number of threads may be any number, for example, in the range of 2 to N threads.

[0015] An aspect provides a method for determining when multiple cache lines associated with a memory region (e.g., a page) are shareable between multiple threads (e.g., a first thread, a second thread, etc.). An instruction fetch from the first thread may request instructions from an address in system memory associated with the memory page. An instruction cache (e.g., L2) set / way pointer (hereinafter referred to as "L2xy") to the instruction cache line is derived from the address in system memory. Generally, it is determined that the instruction cache line is shareable between the first thread and the second thread. In response to the determination, an alias table entry is created in an alias table. The alias table entry indicates that other instruction cache lines associated with the memory page are also shareable between the first thread and the second thread. When processing additional instruction fetches, the cache manager may refer to the alias table entry to determine that other cache lines associated with the memory page are shareable.

[0016] In one aspect, when cache data is returned, a read-modify-write of the instruction cache directory (or "IDIR") is performed to locate individual instruction cache lines that may be shared.

[0017] In another aspect, a tracking table is used to determine when individual cache lines can be shared among multiple threads. L2xy is stored in the iCache directory and used as a surrogate / alternate address for the corresponding real address. If L2xy is the same for two fetches, the memory data for the two iCache misses is also the same. The tracking table can be utilized to find potential sharing candidates. The tracking table is partitioned per thread and can contain one entry per thread. Each entry can contain the effective address (EA), model specific register (MSR) state, and the L2xy pointer. Also included is a reload machine for each in-flight cache miss and a mechanism to manage translation invalidation in an architecturally sound manner.

[0018] The iCache can be an effective address cache in which there is no concept of physical or real addresses, except for an L2xy pointer, which stores a few bits of the real address along with an associative pointer in the instruction cache (e.g., L2). The L2xy pointer allows instruction cache invalidation to be performed when (1) there is a store that modifies a cache line in the instruction cache, or (2) the line is timed out of L2. The L2xy pointer can be compared between threads when an instruction cache line is invalidated, allowing instruction cache lines to be shared by multiple threads if the data is returned for a new thread with a matching L2xy pointer.

[0019] The thread-specific context tag can be used to identify the thread. The thread-specific context tag can be statically mapped to a hardware thread (e.g., ctxttag = tid + 8). Therefore, the tid can be derived from the context tag. The thread-specific context tag can map the current thread or other threads that are not the current thread. An additional shared thread context tag can be used to indicate that the iCache line is shared. The thread-specific context tag can be used to indicate which thread originally loaded the cache line when creating a tracking table entry. Therefore, it is possible to determine which threads are architecturally shareable when L2xy matches and when the reload returns from the instruction cache.

[0020] In this way, the instruction fetch unit (IFU) (not shown) can identify cache lines that have the same EA (i.e., L2xy pointer) and are allowed to hit the same instruction cache line. A tracking table is used to detect sharing and retrieves the L2xy pointer of the current thread when the instruction cache directory (IDIR) is read for the corresponding IDIR miss. Sharing can be remembered via a special context tag value (e.g., 0xF or 1111).

[0021] The tracking table may contain instruction cache directory (IDIR) information related to recent "near misses," which occur when there is an IDIR miss but everything matches except the context tag.

[0022] In general, an entry can be written to the tracking table whenever an instruction cache effective address directory (EADIR) / IDIR miss occurs, provided various conditions are met, such as: 1. EA and MSR are consistent. 2.IEADIR hit and way select were correct if used. 3. The sector valid value is valid. 4. No mistakes due to unnecessary force. 5. The context tag of the current IDIR entry is either a thread-specific context tag or a special (e.g., 0xF) context tag. 6. The context tag of the fetch is a thread-specific context tag. 7. The thread valid value from the IDIR does not include the current thread. The thread valid value stored in the tracking table depends on whether the context tag in the IDIR entry was already a special (e.g., 0xF) context tag or a thread-specific context tag. a. If the context tag of the current IDIR entry is a special (eg, 0xF) context tag, the thread valid value saved is the thread valid value "ORed" with the current IDIR thread valid value. b. If the context tag is a thread-specific context tag (e.g., 8, 9, A, B), the thread effective value is the "OR" of the decode of the context tag bits (2:3) and the current thread. If the condition matches, it means that everything except the context tag matched and is considered an "almost hit." In one embodiment, an "almost hit" includes a comparison of a subset of the EA bits, e.g., EA(39:56), and a miss comparison of other fields. The comparison represents an approximation or superset of conditions that may lead to thread sharing. If the context tag is thread-specific, a tracking table entry can be created upon an almost hit.

[0023] Installing a new tracking table entry may include overwriting an existing entry. The tracking table is installed with the above information saved from the IDIR and EADIR, and the IDIR thread valid values ​​described.

[0024] Based on the tracking table lookup, the IDIR and reload machine are changed from the thread-specific context tag to the shared thread context tag. When the L2xy, EA, and MSR of the instruction cache (e.g., L2) match the tracking table, various fields in the reload machine are modified. For example, the context tag can be modified, e.g., to 0xF, to indicate sharing. The thread effective value from the IDIR can be modified to include a match. The instruction reload unit (IRU) of the lower-level (e.g., L1) instruction cache can be modified to reflect the original miss in its tracking table. This modification is useful to prevent the new line from taking up additional space in the instruction cache.

[0025] For example, if a shared thread context tag of 0xF matches the EA and msr, and the directory shared thread bit is active, it is considered an instruction cache hit.

[0026] By timing the tracking table comparison when data is returned from the cache, the reload machine can be updated and iCache directory entries can be written jointly rather than individually. A similar timing chain can be used for cache invalidation, along with checking the invalidation window. The cache returns L2xy one cycle before the cache data returns, and the cache also returns L2xy for invalidations in a consistent manner on the same interface. The tracking table can be implemented with a periodicity where L2xy is available for tracking table lookup.

[0027] The tracking table can be automatically invalidated when a line is modified due to a cache data return or a cache kill. The cache kill flow can implement a read-modify-write lookup of the IDIR designed for architectural compliance. The tracking table must also compare the unique L2xy of the new line in the tracking table with the in-flight cache kill when there is a cache miss returned from outside the cache that is redefining the line.

[0028] In one aspect, the IDIR is accessed for the particular way where there is an EADIR hit, and the IDIR is not accessed when there is an EADIR miss. A cache demand request is sent only when there is an EADIR miss. This saves power, but utilizes asynchronous tracking table entry generation for demand requests.

[0029] The thread sharing mask in EADIR can implement greedy sharing, so unless multiple misses have the same EA value, the thread sharing mask in EADIR will usually have all bits active. If two different threads use the same EA value for different iCache lines, it is likely that the two copies will deactivate the other thread's thread effective value to allow EADIR to hit their own thread's iCache data.

[0030] The EADIR thread valid value can be invalidated if an ieadir hits the EA and the thread bit is currently on, but one of the other fields that are typically thread-specific, such as the MSR or context tag, causes a full iCache directory to cause a cache miss. If the context tag is something the implementation wants to share between processes, this EADIR invalidation also creates a tracking table entry that stores the current iCache directory.

[0031] The tracking table is asynchronous with the reload machine and L2 demand requests. Therefore, an implementation can compare the EA and MSR of the tracking table entry for the current thread when data returns from the cache to see if the current return matches. Comparing the EA and MSR of the tracking table entry makes it easy to transparently handle flushes and other branch redirects that could delay cache demand requests for an arbitrarily long time after the tracking table is created. This improves performance by making it easy to redirect a tracking table entry after it is created but before the request is sent. If a tracking table entry becomes a demand or prefetch request at some future time, and that demand or prefetch returns from the cache, it may be determined to match the tracking table entry.

[0032] In another approach, there may be a cache demand request cache miss caused by the context tag or the thread-shared mask of the modified context tag, but other directory fields match. When a cache demand request is sent, a tracking table entry is created to track the cache demand request reload machine. This approach takes advantage of the fact that all methods of the IDIR are readable for all accesses, including accesses involving demand requests.

[0033] Thus, the present disclosure provides a method for determining when a cache line can be shared among multiple threads. Without the present teachings, the effective cache size per thread is 1 / N of the total cache, where N is the number of threads. In one aspect, multiple threads (e.g., four threads) can share the entire instruction cache footprint, significantly improving symmetric multiprocessing performance.

[0034] To better understand the features of the present disclosure, it may be useful to describe an example architecture. To that end, Figures 1A and 1B illustrate example computer architectures 100 and 150 that facilitate sharing an instruction cache footprint among multiple threads.

[0035] <Example> 1A, an exemplary computer architecture 100 that facilitates sharing an instruction cache footprint among multiple threads in accordance with an exemplary embodiment is shown. Architecture 100 includes a multithreaded processor 101, a cache manager 102, a system memory 104, an instruction cache 108, and an alias table 117. As further depicted, multithreaded processor 101 includes threads 101A, 101B, ..., 101N. In one embodiment, processor 101 includes four threads.

[0036] The cache manager 102 may implement, include, or interoperate with or be a combination of various other components of a memory management system, including, but not limited to, a memory management unit (e.g., configured to translate between real addresses and EAs), one or more reload machines, a cache control and data flow component, a cache predecode component, an instruction cache write data flow component, an instruction decode component, buffers, an issue component, an execution component, a load / store component, an instruction fetch address register, an instruction fetch component, a branch prediction component, an instruction sequencing component, etc.

[0037] Instruction cache 108 may be an N-way associative cache containing M sets, where N is a number between two (2) and twelve (12), and M is a number between four (4) and one hundred and twenty-eight (128). In one embodiment, instruction cache 108 contains 64 sets of 6-ways.

[0038] In a more particular embodiment, the instruction cache 108 is the first level (e.g., L1) of the memory hierarchy accessed when fetching instructions. The instruction cache 108 can store the PPC bits of instructions as well as their associated pre-decode / branch-recode bits. The instruction cache 108 can receive reload data from a second level (e.g., L2) interface. The output to the second level cache is routed through a memory management unit (which can translate real addresses (RAs) to EAs). The output to the second level cache also provides instructions to decode, pre-decode / branch-recode bits to branch scan logic, and pre-decode bits to decode and fusion logic.

[0039] The instruction cache 108 may include the following attributes: It is 48kB and implemented as 8 macros. EA index and tagged EAs. 64 sets (index is EA[51:56]). The tag is EA[0:50]. eadirEA Predicting way selects using a 6-way associative array with an index array. 128 byte cache line. Four 32-byte sectors per cache line. One read port and one write port. Reads up to eight instructions at a time. Writes sector at a time. 12 macros, arranged in a 4x3 matrix. 8R / W bank. A pseudo-LRU purging policy implemented using an MRU tree. Equipped with 6T-SRAM cells, it is capable of dual-ended read and write.

[0040] In computer architecture 100, sharing detector 123 is generally configured to detect when a cache line is sharable among multiple threads 101A, 101B, ..., 101N. For example, sharing detector 123 may perform a read modify of an instruction cache directory (or "IDIR"), e.g., IDir 106, when cache data is returned to locate potentially sharable individual instruction cache lines. When sharing detector 123 determines that a cache line is sharable among multiple threads among 101A, 101B, ..., 101N, cache manager 102 may identify a memory page associated with the cache line. Cache manager 102 may write an alias entry to alias table 117. The alias entry may indicate that one or more additional (possibly all) cache lines associated with the memory page may be shared among multiple threads among 101A, 101B, ..., 101N.

[0041] Table 1 shows example attributes for an alias table entry. [Table 1]

[0042] Alias ​​table 117 may be a structure containing EAs representing regions (e.g., 4k) identified as shared between two or more threads. Alias ​​table 117 may also contain optional information to verify that the translations of the accessing threads match from the time they were assigned (e.g., facilitated by an MSR bit).

[0043] Two threads can be marked as valid for a given entry in alias table 117 if the translation of that EA for all threads leads to the same RA. If the translation of an EA does not match the other thread marked as valid for that entry, a hit in alias table 117 can be prevented. When the translation changes, the MMU can drive an invalidation on the interface. Invalidating the translation can also invalidate any learned sharing. Therefore, alias table 117 can be updated to maintain architectural correctness.

[0044] The number of entries in the alias table 117 can vary. In one embodiment, the alias table 117 contains 8 or 16 entries.

[0045] 1B, an exemplary computer architecture 150 that facilitates sharing an instruction cache footprint among multiple threads in accordance with an exemplary embodiment includes a multithreaded processor 101, a cache manager 102, a system memory 104, an IDir 106, a tracking table 107, an instruction cache 108, an alias table 117, and an EAdir 131.

[0046] The cache manager 102 can use EADir 131 to select which way the instruction cache 108 is accessed and provide early indication of instruction cache misses / hits. For example, EADir 131 can provide a 6-bit method selection of one-hot based on EA compare and thread valid bits. The thread mask thread valid bits enable sharing between threads by supporting entries valid for multiple threads at a time.

[0047] EADir 131 can include the following attributes: 64 sets of 6-way. Set indexed by EA (51:56). One physical directory. One read port and one write port. Reading and writing to the same cell is not allowed, and this collision is detected outside the iCache. Writes only on the first iCache write. Each way is compared with EA(39:50) and the thread valid bit to generate a way select. Total: 64 sets x 16 bits / way x 6 ways. The bypass comes from outside the instruction cache 108 . 10T-SRAM cell (optimized for speed).

[0048] Table 2 shows an example of the EADir bit definition. [Table 2]

[0049] The IDir 106 can be a tag store for the instruction cache 108. The IDir 106 can be used to perform true instruction cache hit detection by performing tag comparisons. In one aspect, the IDir 106 also stores valid bits, parity bits, MSR bits, page size bits, and bits for handling SLB / TLB invalidations.

[0050] IDir 106 can include the following attributes: 64 sets of 6-way. Mirror iCache / EADir. EA(51:56) Index. 6 growable cash register files. One register file for each way, i.e., each register file is 64 sets x 84 bits. When the sector value is updated, IDir 106 can be written four times per cache line (per iCache sector write), but EADir can only be written once.

[0051] Table 3 shows an example of IDir bit definition. [Table 3]

[0052] As described, a context tag (e.g., CTAG) may be used for each thread. In one aspect, the context tag (e.g., if there are four threads) may be a four (4) bit value including values ​​1000, 1001, 1010, 1011, and 1111. Ctxt tag=1000 Private context tag of tid0 for process of tid0 Ctxt tag=1001 Private context tag of tid1 for process of tid1 Ctxt tag=1010 Private context tag of tid2 for process of tid2 Ctxt tag=1011 Private context tag of tid3 for process of tid3 Ctxt tag=1111, the changed context tag mmu context tag is shared by the thread indicated by the thread bit in the iCache directory A thread-specific context tag can be used to indicate which thread originally loaded the iCache line when creating a tracking table entry.

[0053] The thread value can be received from the memory management unit (MMU) or contained in the context tag. For Ctxt tag=1111, the thread indicates which threads are architecturally determined to share the page when the cache line is written.

[0054] The context table can contain pointers to the LPID&PID registers. When the context table is searched, there can be no multiple hits for a given EA(0:1), LPCR(Radix), LPCR(UPRT), MSR(HV), and MSR(DR) bits. The 2-bit pointer references either the LPIDR / PIDR registers, or possibly both. If threads match, their pointers point to the same set of registers, so when the context table is searched, no two tags can point to the same combination of LPID and PID.

[0055] The instruction cache 108 may utilize a binary tree pseudo-Least Recently Used (LRU) replacement policy. In one aspect, the two subtrees are three (3)-way associative true LRU.

[0056] EADir 131 can store L thread sharing bits, where L is the number of threads (e.g., 4). EADir 131 can contain the sharing making for the thread associated with the entry. IDir 106 can also utilize a sharing mask sent from the MMU on iCache / IDir writes. On invalidation, the sharing mask can indicate which other threads are invalidated when one thread invalidates a shared cache line (e.g., in the instruction cache 108).

[0057] There are different situations in which a shared cache line can be invalidated, including: (1) EADir hit, IDir miss: EADir falsely detects an initial hit. The IDir miss is received later, allowing us to determine how to invalidate it. This invalidation scenario is also used to create a tracking table entry for the access. (2) EADir multi-hit: generated by prefetch (EADir may not be searched by prefetch, but IDIR is). Prefetch can write the mask of the parent demand request (obtained from rldm) to EADir. (3) Collision during line write: If there is an L2 invalidation while returning L2 data, the sector being written will be dropped and partial thread valid values ​​will be obtained because the invalidation takes precedence in the case of a collision. (4) The RLDM is reallocated for subsequent misses while the data from the first request is being written to the iCache.

[0058] Invalidation of EADir can be a read-modify-write operation that occurs during a particular instruction fetch (IF) stage. During an earlier IF stage, the cache manager 102 can read EADir 131. During this early IF stage, the EAs (e.g., EA[49:56]) and thread masks are known. The EAs and thread masks are carried to a later IF stage when an invalidation latch is available. During this later IF stage, the cache manager 102 can write EADir 131 with the thread masks with the bits of the threads to be invalidated set to zero.

[0059] If there is an EADir write in an intermediate IF stage (for example, between an earlier IF stage and a later IF stage), or if there is an iCache write conflict in a later IF stage, the invalidation can be delayed and the IFAR can be triggered once the operation reaches the later IF stage. Such invalidation operations should be performed carefully; the next time the EADir 131 / iCache 108 is accessed, the invalidation situation can be redetected and another invalidation attempt can be made.

[0060] EADir131 can be "almost hit". If the instruction EA of EADir131 matches, the EADir entry is invalid for the accessing thread but valid for other threads. The match is latched up after the EADir access, and the thread mask is saved in the reload machine for subsequent iCache misses. Of the EADir, thread_valids(0:3) and almost_way(0:3) can be evaluated for each of the six ways.

[0061] The tracking table 107 can store IDIR information related to recent "near misses." As explained, a "near miss" can occur when an IDIR miss occurs but everything matches except the context tag. The tracking table 107 can associate IDir 106 entries with reloads that may share threads across IDIR entries. The allocation and use of the tracking table 107 can be used for threads with thread-specific context tags. Both the current thread and the fetching thread can correspond to thread-specific tags.

[0062] Table 4 shows an example of tracking attributes for a table entry. [Table 4]

[0063] The tracking table 107 may be partitioned per thread, containing one entry per thread. The tracking table 107 may be used independently as a cache line granular sharing mechanism.

[0064] A subsequent hit in tracking table 107 indicates that the instruction cache line can be shared among multiple threads from among 101A, 101B, ..., 101N. Thus, when a hit in tracking table 107 occurs, cache manager 102 can identify the memory page associated with the corresponding instruction cache line. Cache manager 102 can write an alias entry to alias table 117. The alias entry can indicate that one or more additional (possibly all) cache lines associated with the memory page can be shared among multiple threads from among 101A, 101B, ..., 101N.

[0065] 2 illustrates a flowchart of an exemplary method 200 for sharing instruction cache lines among multiple threads in accordance with an exemplary embodiment. Method 200 will be described with respect to components of computer architectures 100 and 150.

[0066] Thread 101A may send instruction fetch 111A for instruction 112 to cache manager 102. Cache manager 102 may determine that instruction 112 is not cached. In response, cache manager 102 may fetch instruction 112 from (memory) page 141 of system memory 104. Cache manager 102 may derive L2xy 113A from the address of page 141 to cache line 108A. The cache manager may cache instruction 112 in cache line 108A.

[0067] Method 200 includes receiving an instruction fetch from a first thread, the instruction fetch requesting an instruction from an address in system memory associated with a memory page (202). For example, cache manager 102 may receive instruction fetch 111A from thread 101B. Instruction fetch 111A may request instruction 112 from page 141 of system memory 104. Method 200 includes deriving (204) a set / way pointer to an instruction cache line from the address of the memory address. For example, cache manager 102 may derive L2xy113A from the memory address of page 141. Cache manager 102 may determine that L2xy113A corresponds to cache line 108A and may cache instruction 112 in cache line 108A.

[0068] Method 200 includes receiving another instruction fetch from a second thread, the other instruction fetch requesting an instruction from another address in system memory associated with the memory page (206). For example, cache manager 102 may receive instruction fetch 111B from thread 101B. Instruction fetch 111B may request instruction 112 from page 141 of system memory 104. Method 200 includes deriving another set / way pointer to another instruction cache line from the other address in system memory (208). For example, cache manager 102 may derive L2xy113B from the other memory address in page 141.

[0069] When it is detected that the set / way pointer and the other set / way pointer both point to an instruction cache line, it determines that the instruction cache line is shareable between the first thread and the second thread (210). For example, in FIG. 1A, sharing detector 123 may perform a read-modify-write of IDir 106 when cache data is being returned from cache line 108A to determine whether cache line 108A is shareable between threads 101A and 101B. The sharing detector may compare L2xy 113A and L2xy 113B. In one aspect, when L2xy 113A and L2xy 113B both point to cache line 108A, sharing detector 123 determines that cache line 108A is shareable between (at least) threads 101A and 101B.

[0070] 1B , in another aspect, cache manager 102 may store L2xy 113A in IDir 106 in combination with caching instruction 112 for instruction cache line 108A. Subsequently, when instruction fetch 111B is received, cache manager 102 may determine that the memory address associated with instruction fetch 111B is a candidate for sharing.

[0071] Cache manager 102 may store L2xy 113A from IDir 106 in tracking table 107. Cache manager 102 may derive L2xy 113B from a memory address associated with instruction fetch 111B. Cache manager 102 may access L2xy 113A from tracking table 107. Pointer comparator 103 may compare L2xy 113A and L2xy 113B. Based on the comparison, pointer comparator 103 may determine that L2xy 113A and L2xy 113B both point to instruction cache line 108A and therefore cache line 108A is shareable between (at least) threads 101A and 101B. In response to the detected sharing, cache manager 102 may update 114 IDir 106 to indicate that instruction cache line 108A is shared between threads 101A and 101B. Indicating the sharing of the instruction cache line 108A may include modifying the context tag of the IDir 106.

[0072] Instruction cache line 108A may also be returned to either thread 101A or thread 101B in response to a subsequent request for instruction 112 from either thread 101A or thread 101B.

[0073] Similar operations may be performed to determine that cache line 108A is shareable with one or more additional threads of processor 100. Instruction cache line 108A may then be returned to any of the one or more additional threads in response to a subsequent request for instruction 112 from any of the one or more additional threads.

[0074] In one aspect, the cache manager 102 installs a tracking table entry in the tracking table 107. The cache manager 102 can install a tracking table entry when there is an EADir miss / IDIR miss and other conditions are met. The conditions may include: 1. EA and MSR are consistent. 2. EADIR hit and way select were correct if used. 3. The sector valid value is valid. 4. No mistakes due to unnecessary force. 5. The context tag of the current IDIR entry is either a thread-specific context tag or a 0xF context tag. 6. The context tag of the fetch is a thread-specific context tag. 7. The thread valid value from the IDIR does not include the current thread. The thread valid value stored in the tracking table depends on whether the context tag in the IDIR entry was already 0xF or a thread-specific context tag. a. If the context tag of the current IDIR entry is 0xF, then the thread valid value saved is the current thread valid value "or'ed" with the current IDIR thread valid value. b. If the context tag is a thread-specific context tag of 8, 9, A, or B, the thread effective value is the current thread decoding of the context tag bits (2:3). (This also covers cases where LSU says it can't share lines between threads due to IAMR etc.) If these conditions are met, it can be assumed that everything except the context tag matches, and it is considered an "almost hit."

[0075] The tracking table 107 may include one entry per thread. Installing a new tracking table entry in the tracking table 107 may include overwriting an existing entry. The tracking table 107 may be installed using the information described, for example, in conjunction with the IDIR thread valid values ​​described in conditions 7a and 7b, saved from the IDir 106 and EADir 131. In one embodiment, the tracking table 107 may be used at reload time.

[0076] Entries in tracking table 107 can be thought of as pointers to entries in IDir 106. Therefore, in general, invalidation rules for IDir 106 can also be applied to entries in tracking table 107.

[0077] Upon determining that the instruction cache line is shareable between the first thread and the second thread, method 200 includes creating an alias table entry in an alias table indicating that other instruction cache lines associated with the memory page are also shareable between the first thread and the second thread (212). For example, cache manager 102 may create entry 118 in alias table 117. Entry 118 may indicate that other instruction cache lines in instruction cache 108 associated with page 141 are also shareable between (at least) threads 101A and 101B.

[0078] Thread 101A may then request additional instructions from page 141. Cache manager 102 may fetch the additional instructions from further memory addresses in page 141 and cache the additional instructions in cache line 108B.

[0079] Following creating the alias table entry, method 200 includes receiving a further instruction fetch from a second thread, the further instruction fetch requesting an instruction from a further system memory address associated with the memory page (214). For example, cache manager 102 may receive a further instruction fetch from thread 101B requesting an instruction from a further memory address (different from the memory address of instruction 112) within page 141.

[0080] Method 200 includes deriving a further set / way pointer from the further system memory address to a further instruction cache line, where the further instruction cache line caches instructions fetched from the further system memory address by the first thread (216). For example, cache manager 102 may derive a set / way pointer from the further system memory address to instruction cache line 108B. As described, cache line 108B may cache additional instructions previously fetched from the further memory address in page 141 by thread 101A.

[0081] Method 200 includes determining (218) that an additional instruction cache line is shareable with the second thread based on the alias table entry. For example, cache manager 102 may reference entry 118 in alias table 117. Based on entry 118, cache manager 102 may determine that instruction cache line 108B is shareable between (at least) threads 101A and 101B. Instruction cache line 108B may then be returned to thread 101B.

[0082] Similar operations can be performed to determine that other cache lines, such as instruction cache line 108C, can be shared with (at least) threads 101A and 101B based on the instructions cached in the instruction cache line being associated with a memory address of page 141. Instructions cached in instruction cache lines of instruction cache 108 can be returned to threads of processor 100 in response to an instruction fetch. When instruction cache lines are shared, one thread can access cached instructions originally cached for a different thread.

[0083] In one aspect, a thread from among threads 101A and 101B fetches a further instruction cache line from instruction cache 108. For example, a further instruction fetch for a further instruction from a third thread (e.g., 101N) is received. A further set / way pointer associated with the further instruction fetch is derived. The further set / way pointer is saved. A cache miss is detected for the third thread on the further instruction line. A request for the further instruction is sent by the higher (e.g., L2) cache. An instruction cache line is received from a higher-level cache. Further set / way pointers are matched against tracking table 107. Cache manager 102 determines whether the thread sharing masks between the tracking table and the alias table overlap. Cache manager 102 updates alias table 117 to indicate that the instruction cache line associated with page 141 is shareable between threads 101A, 101B, and 101N.

[0084] 3 illustrates a computer hardware platform 300 that is specifically configured in accordance with an exemplary embodiment. The computer hardware platform 300 can be used to implement a computer system that includes the components of the computer architecture 100.

[0085] The computer platform 300 may include a central processing unit (CPU) 304, a hard disk drive (HDD) 306, a random access memory (RAM) and / or read-only memory (ROM) 308, a keyboard 310, a mouse 312, a display 314, and a communication interface 316 connected to a system bus 302.

[0086] The HDD 306 may include functionality for storing programs to be executed.

[0087] The CPU 304 may include functionality for storing data and executing programs therein. The CPU 304 may include a processor 101 (and corresponding threads), a cache manager 102, an IDir 106, a tracking table 107, an alias table 117, an instruction cache 108, an EADir 131, and multiple registers. Aspects of the present disclosure may be implemented within the CPU 304.

[0088] The RAM / ROM 308 may include the system memory 104 .

[0089] Programs executing within CPU 304 can access data and instructions from pages of system memory 104 via system bus 302. If appropriate, accessed data and instructions may be cached within CPU 304. For example, accessed instructions may be cached in instruction cache 108.

[0090] 4 illustrates an exemplary memory architecture 400. Aspects of the present disclosure may be implemented in memory architecture 400 or other similar memory architectures. As shown, the memory architecture includes a processor thread 401 and a memory hierarchy 407. Processor thread 401 includes threads 401A, 401B, ..., 401N. Memory hierarchy 407 includes a cache layer 402 (e.g., L1), a cache layer 403 (e.g., L2), a cache layer 404 (e.g., L3), and a system memory 406.

[0091] Within memory hierarchy 407, memory elements used to form cache tiers closer to processor thread 401 may be faster than memory elements used to form tiers further from processor thread 401. To balance costs, cache tiers closer to processor thread 401 may have less capacity than cache tiers further from processor thread 401. For example, cache tier 402 may be faster than cache tier 403 but have less capacity than cache tier 403. System memory 406 may be slower than cache tiers 402, 403, and 404 but have significantly greater capacity than cache tiers 402, 403, and 404.

[0092] A thread within processor threads 401 may submit an instruction fetch request to the memory hierarchy requesting an instruction. For example, thread 401B may submit instruction fetch 411 to memory hierarchy 407 requesting instruction 412. Cache layer 402 may check instruction 412. If instruction 412 is cached in cache layer 402, instruction 412 may be returned from cache layer 402 to thread 401B.

[0093] If instruction 412 is not cached in cache layer 402, cache layer 403 can check instruction 412. If instruction 412 is stored in cache layer 403, instruction 412 can be cached in cache layer 402 and returned to thread 401B.

[0094] If instruction 412 is not cached in cache layer 403, cache layer 404 can check instruction 412. If instruction 412 is cached in cache layer 404, instruction 412 can be cached in cache layers 403 and 402 and returned to thread 401B.

[0095] If instruction 412 is not cached in cache layer 404, system memory 406 can check for instruction 412. If instruction 412 is stored in system memory 406, instruction 412 can be cached in cache layers 404, 403, 402 and returned to thread 401B.

[0096] The instruction cache 108 may be implemented in any of the cache layers 402, 403, 404. In one aspect, the instruction cache 108 is implemented in layer 402 (L1).

[0097] <Examples of operating platforms> An implementation may configure or utilize a special-purpose or general-purpose computer, including, for example, one or more computer or hardware processors (including any of a central processing unit (CPU), or graphics processing unit (GPU), general-purpose GPU (GPGPU), field programmable gate array (FPGA), application-specific integrated circuit (ASIC), tensor processing unit (TPU), or combination thereof), and computer hardware such as system memory, discussed in more detail below. An implementation also includes physical and other computer-readable media for carrying or storing computer-executable instructions or data structures, or both. Such computer-readable media may be any available media accessible by a general-purpose or special-purpose computer system. Computer-readable media that store computer-executable instructions are computer storage media (devices). Computer-readable media that transmit computer-executable instructions are transmission media. Thus, by way of example and not limitation, an implementation may be comprised of at least two different types of computer-readable media: computer storage media (devices) and transmission media. Computer storage media (devices) include SCM (and other intermediate storage solutions), RAM, ROM, EEPROM, CD-ROM, solid state drives ("SSDs") (e.g., RAM-based or flash-based), shingled magnetic recording ("SMR") devices, flash memory, phase change memory ("PCM"), other types of memory, other optical disk storage, magnetic disk storage or other magnetic storage, or any other medium that can be used to store desired program code means in the form of computer-executable instructions or data structures and that can be accessed by a general-purpose or special-purpose computer.

[0098] In one aspect, one or more processors are configured to execute instructions (e.g., computer-readable instructions, computer-executable instructions, etc.) to perform any of the described operations. The one or more processors can access information from and / or store information in system memory. The one or more processors can convert information (e.g., automatically) between different formats, such as between any of volume commands, volume metadata, queries, volume configurations, volume reconfigurations, persistence loss notifications, persistence loss detections, etc.

[0099] The system memory may be coupled to one or more processors and may store instructions (e.g., computer-readable instructions, computer-executable instructions, etc.) executed by the one or more processors. The system memory may also be configured to store any of several other types of data generated and / or transformed by the described components, such as, for example, volume commands, volume metadata, queries, volume configurations, volume reconfigurations, persistence loss notifications, persistence loss detections, etc.

[0100] A "network" is defined as one or more data links that enable the transmission of electronic data between computer systems or modules or other electronic devices, or a combination thereof. When information is transferred or provided to a computer over a network or other communications connection (either hardwired, wireless, or a combination of hardwired or wireless), the computer properly views the connection as a transmission medium. A transmission medium may be used to transmit desired program code means in the form of computer-executable instructions or data structures and may include a network or data links, or both, that can be accessed by a general-purpose or special-purpose computer. Combinations of the above should also be included within the scope of computer-readable media.

[0101] Furthermore, upon reaching various computer system components, program code means in the form of computer-executable instructions or data structures may be automatically transferred from transmission media to computer storage media (devices) (or vice versa). For example, computer-executable instructions or data structures received over a network or data link may be buffered in RAM within a network interface module (e.g., a "NIC") and then ultimately transferred to the computer system's RAM and / or less-volatile computer storage media (devices). Thus, it should be understood that computer storage media (devices) may be included in computer system components that also (or primarily) utilize transmission media. Computer-executable instructions comprise, for example, instructions and data that, when executed by a processor, cause a general-purpose computer, special-purpose computer, or special-purpose processing device to perform a certain function or group of functions. Computer-executable instructions may be, for example, binaries, intermediate format instructions such as assembly language, or source code. While the subject matter has been described in language specific to structural features or methodological acts, or both, it will be understood that the subject matter defined in the appended claims is not necessarily limited to the described features or acts. Rather, the described features and acts are disclosed as example forms of implementing the claims.

[0102] Those skilled in the art will appreciate that the described aspects may be implemented in networked computing environments having many types of computer system configurations, including personal computers, desktop computers, laptop computers, message processors, handheld devices, wearable devices, multi-core processor systems, multiprocessor systems, microprocessor-based or programmable consumer electronics, network PCs, minicomputers, mainframe computers, mobile phones, PDAs, tablets, routers, switches, etc. The described aspects may also be implemented in distributed system environments where tasks are performed together by local and remote computer systems that are linked through a network (either by hardwired data links, wireless data links, or a combination of hardwired and wireless data links). In a distributed system environment, program modules may be located in both local and remote memory storage devices.

[0103] Furthermore, where appropriate, the functions described herein may be implemented by one or more of hardware, software, firmware, digital components, or analog components. For example, one or more field programmable gate arrays (FPGAs), one or more application specific integrated circuits (ASICs), or one or more tensor processing units (TPUs), or a combination thereof, may be programmed to execute one or more of the systems and procedures described herein. The hardware, software, firmware, digital components, or analog components may be specifically tailored and designed to (re)configure volumes on more volatile storage devices in response to a loss of persistence. In other examples, computer code may include hardware logic / electrical circuitry configured to run on one or more processors and controlled by the computer code. These exemplary devices are provided herein for purposes of illustration and are not intended to be limiting. Embodiments of the present disclosure may be implemented in additional types of devices.

[0104] The described aspects may also be implemented in a cloud computing environment. For purposes of this specification and the following claims, "cloud computing" is defined as a model that enables on-demand network access to a shared pool of configurable computing resources. For example, cloud computing may be adopted in markets to provide ubiquitous, convenient, on-demand access to a shared pool of configurable computing resources (e.g., compute, network, and storage resources). The shared pool of configurable computing resources is provisioned through virtualization, released with little effort or service provider interaction, and then scales accordingly.

[0105] Cloud computing models can include various characteristics, such as, for example, on-demand self-service, broad network access, resource pooling, rapid elasticity, and measured service. Cloud computing models can also expose various service models, such as, for example, Software as a Service ("SaaS"), Platform as a Service ("PaaS"), and Infrastructure as a Service ("IaaS"). Cloud computing models can also be deployed using different deployment models, such as private cloud, community cloud, public cloud, and hybrid cloud. As used herein and in the claims that follow, a "cloud computing environment" refers to an environment in which cloud computing is employed.

[0106] <Conclusion> The description of various embodiments of the present teachings is presented for illustrative purposes, but is not intended to be exhaustive or limited to the disclosed embodiments. It will be apparent to those skilled in the art that many modifications and variations are possible without departing from the scope of the described embodiments. The terms used herein have been selected to best explain the principles of the embodiments, practical applications or technical improvements to technology found in the market, or to enable those skilled in the art to understand the embodiments described herein.

[0107] While the foregoing describes what is considered to be the best mode and / or other embodiments, it is to be understood that various modifications may be made thereto, that the subject matter disclosed herein may be embodied in various forms and embodiments, and that the present teachings may be applied to numerous applications, only a few of which have been described herein. It is intended by the following claims to claim all such applications, modifications, and variations that fall within the true scope of the present teachings.

[0108] The components, steps, features, objects, benefits, and advantages discussed herein are merely exemplary. None of them, nor the discussion related thereto, are intended to limit the scope of protection. While various advantages have been discussed herein, it will be understood that not all embodiments necessarily include all advantages. Unless otherwise specified, all measurements, values, ratings, positions, dimensions, sizes, and other specifications set forth in this specification, including the following claims, are approximate rather than precise. They are intended to have a reasonable range consistent with the functions to which they relate and customary practices in the technical field to which they pertain.

[0109] Numerous other embodiments are contemplated, including embodiments having fewer, additional, or different, or combinations of, components, steps, features, objects, benefits, and advantages, including embodiments in which the components or steps are arranged and / or ordered differently.

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

[0111] These computer-readable program instructions can be provided to a processor of a computer, special purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions, when executed by the processor of the computer or other programmable data processing apparatus, create means for performing the function(s) / act(s) specified in a block or blocks, or combinations thereof, of the call flow process or block diagram. These computer-readable program instructions can also be stored on a computer-readable storage medium, or combinations thereof, that can direct a computer, programmable data processing apparatus, or other device to function in a particular manner, such that the computer-readable storage medium having instructions stored therein constitutes an article of manufacture containing instructions that perform an aspect of the function(s) / act(s) specified in a block or blocks, or combinations thereof, of the call flow or block diagram.

[0112] The computer-readable program instructions may also be loaded into a computer, other programmable data processing device, or other device to cause the computer, other programmable device, or other device to execute a series of operational steps to generate a computer-implemented process, such that the instructions executing on the computer, other programmable device, or other device perform the function / act specified in a block or blocks, or a combination of blocks, of the call flow process or block diagram.

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

[0114] While the foregoing has been described in connection with exemplary embodiments, it is understood that the term "exemplary" is meant merely as exemplary, not as best or optimal. Except as noted immediately above, nothing described or illustrated is intended to, or should be construed to, generally dedicate any component, step, feature, object, benefit, advantage, or equivalent, whether or not claimed.

[0115] Terms and phrases used herein shall be understood to have the ordinary meanings given to such terms and phrases in relation to their respective fields of study, unless a special meaning is provided herein. Relative terms, such as "first" and "second," are used solely to distinguish one entity or act from another and do not necessarily require or imply an actual relationship or sequence between such entities or acts. The use of "comprises" or other variations thereof is intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus consisting of a list of elements may include, rather than only those elements, other elements not expressly listed or inherent in such process, method, article, or apparatus. An element denoted by "a" or "an" does not, without further constraints, preclude the presence of additional identical elements in the process, method, article, or apparatus that comprises that element.

Claims

1. 1. A computing device comprising: a multi-threaded processor comprising a plurality of processing threads having at least a first thread and a second thread; an instruction cache coupled to the multithreaded processor and to a system memory; a cache manager coupled to the instruction cache, wherein execution of the cache manager by the multithreaded processor causes the computing device to perform an operation, the operation comprising: determining that an instruction cache line of the instruction cache is shareable between the first thread and the second thread; creating an alias table entry in an alias table indicating that other instruction cache lines associated with a memory page of a system memory may also be shared between the first thread and the second thread; receiving a further instruction fetch from the second thread, the further instruction fetch requesting an instruction from a further address in the system memory associated with the memory page; deriving a further set / way pointer to a further instruction cache line from the further address of the system memory, the further instruction cache line caching instructions fetched from the further address of the system memory by the first thread; determining, based on the alias table entry, that the further instruction cache line is shareable with the second thread.

2. receiving an instruction fetch from the first thread, the instruction fetch requesting an instruction from an address in the system memory associated with the memory page; deriving a set / way pointer from the address in the system memory; receiving another instruction fetch from the second thread, the other instruction fetch requesting an instruction from another address in the system memory associated with the memory page; and deriving another set / way pointer from the other address in the system memory; determining that the instruction cache line is shareable between the first thread and the second thread includes detecting that the set / way pointer and the other set / way pointer both point to the instruction cache line; The computing device of claim 1 , wherein receiving the further instruction fetch comprises receiving the further instruction fetch after creating the alias table entry.

3. The computing device of claim 1 , further comprising: in response to the further instruction fetch, returning the further instruction cache line to the second thread.

4. 2. The computing device of claim 1, wherein determining that the instruction cache line is shareable between the first thread and the second thread comprises performing an instruction cache directory read-modify-write when cache data is returned from the instruction cache line.

5. 2. The computing device of claim 1, wherein determining that the instruction cache line is shareable between the first thread and the second thread comprises accessing a set / way pointer from a tracking table.

6. Executing the cache manager further comprises: a thread fetching an additional instruction cache line into the instruction cache from the first thread or the second thread; receiving an additional instruction fetch for an additional instruction from a third thread included in the plurality of processing threads; deriving further set / way pointers associated with said additional instruction fetches; and storing further set / way pointers; detecting a cache miss of the third thread for the additional instruction cache line; and sending the request for the additional instructions to an L2 cache.

7. Executing the cache manager further comprises: receiving an L2 cache line; matching said further set / way pointers to a tracking table; and determining whether thread sharing masks between the tracking table and the alias table overlap.

8. Executing the cache manager further comprises: updating the alias table to indicate that an instruction cache line associated with the memory page is shareable among the first thread, the second thread, and the third thread; and marking and overwriting the additional instruction cache line shared by the first thread, the second thread, and the third thread upon a cache miss of the third thread.

9. the instruction cache is an N-way associative cache; The computing device of claim 1 , wherein the multithreaded processor comprises a multithreaded processor including three or more threads.

10. 1. A computer-implemented method for sharing an instruction cache footprint, comprising: determining that an instruction cache line is shareable between a first thread and a second thread; creating an alias table entry in an alias table indicating that other instruction cache lines associated with a memory page of a system memory may also be shared between the first thread and the second thread; receiving a further instruction fetch from the second thread, the further instruction fetch requesting an instruction from a further address in the system memory associated with the memory page; deriving a further set / way pointer to a further instruction cache line from the further address of the system memory, the further instruction cache line caching instructions fetched from the further address of the system memory by the first thread; determining, based on the alias table entry, that the further instruction cache line is shareable with the second thread.

11. receiving an instruction fetch from the first thread, the instruction fetch requesting an instruction from an address in the system memory associated with the memory page; deriving a set / way pointer from the address in the system memory; receiving another instruction fetch from the second thread, the other instruction fetch requesting an instruction from another address in the system memory associated with the memory page; and deriving another set / way pointer from the other address in the system memory; determining that the instruction cache line is shareable between the first thread and the second thread includes detecting that the set / way pointer and the other set / way pointer both point to the instruction cache line; 11. The computer-implemented method of claim 10, wherein receiving the further instruction fetch comprises receiving the further instruction fetch after creating the alias table entry.

12. 11. The computer-implemented method of claim 10, further comprising returning the further instruction cache line to the second thread in response to the further instruction fetch.

13. 11. The computer-implemented method of claim 10, wherein determining that the instruction cache line is shareable between the first thread and the second thread comprises performing an instruction cache directory read-modify-write when cache data is returned from the instruction cache line.

14. 11. The computer-implemented method of claim 10, wherein determining that the instruction cache line is shareable between the first thread and the second thread comprises accessing a set / way pointer from a tracking table.

15. Executing the cache manager further comprises: a thread fetching an additional instruction cache line into the instruction cache from the first thread or the second thread; receiving an additional instruction fetch for an additional instruction from a third thread; deriving further set / way pointers associated with said additional instruction fetches; and storing further set / way pointers; detecting a cache miss of the third thread for the additional instruction cache line; and sending the request for the additional instructions to an L2 cache.

16. Executing the cache manager further comprises: receiving an L2 cache line; matching said further set / way pointers to a tracking table; and determining whether thread sharing masks between the tracking table and the alias table overlap.

17. Executing the cache manager further comprises: updating the alias table to indicate that an instruction cache line associated with the memory page is shareable among the first thread, the second thread, and the third thread; and marking and overwriting the additional instruction cache line shared by the first thread, the second thread, and the third thread with a cache miss of the third thread.

18. A computer program product that, when executed, causes a user equipment to perform a method for sharing an instruction cache footprint, the method comprising: determining that an instruction cache line is shareable between a first thread and a second thread; creating an alias table entry in an alias table indicating that other instruction cache lines associated with a memory page of a system memory may also be shared between the first thread and the second thread; receiving a further instruction fetch from the second thread, the further instruction fetch requesting an instruction from a further address in the system memory associated with the memory page; deriving a further set / way pointer to a further instruction cache line from the further address of the system memory, the further instruction cache line caching instructions fetched from the further address of the system memory by the first thread; determining, based on the alias table entry, that the further instruction cache line is shareable with the second thread.

19. The method comprising: receiving an instruction fetch from the first thread, the instruction fetch requesting an instruction from an address in the system memory associated with the memory page; deriving a set / way pointer from the address in the system memory; receiving another instruction fetch from the second thread, the other instruction fetch requesting an instruction from another address in the system memory associated with the memory page; and deriving another set / way pointer from the other address in the system memory; determining that the instruction cache line is shareable between the first thread and the second thread includes detecting that the set / way pointer and the other set / way pointer both point to the instruction cache line; 20. The computer program product of claim 18, wherein receiving the further instruction fetch comprises receiving the further instruction fetch after creating the alias table entry.

20. receiving an instruction fetch from the first thread includes receiving the instruction fetch from the first thread of a multithreaded processor; receiving another instruction fetch from the second thread includes receiving the other instruction fetch from the second thread of the multithreaded processor; 20. The computer program product of claim 19, wherein deriving the set / way pointers comprises deriving set / way pointers to instruction cache lines of an N-way associative cache.

21. The method comprising:

20. The computer program product of claim 18, further comprising returning the further instruction cache line to the second thread in response to the further instruction fetch.

22. 20. The computer program product of claim 18, wherein determining that the instruction cache line is shareable between the first thread and the second thread comprises performing an instruction cache directory read-modify-write when cache data is returned from the instruction cache line.

23. 20. The computer program product of claim 18, wherein determining that the instruction cache line is shareable between the first thread and the second thread comprises accessing a set / way pointer from a tracking table.

24. The method comprising: a thread fetching an additional instruction cache line into the instruction cache from the first thread or the second thread; receiving an additional instruction fetch for an additional instruction from a third thread; deriving further set / way pointers associated with said additional instruction fetches; and storing further set / way pointers; detecting a cache miss of the third thread for the additional instruction cache line; and sending the request for the additional instructions to an L2 cache.

25. The method comprising: receiving an L2 cache line; matching said further set / way pointers to a tracking table; and determining whether thread sharing masks between the tracking table and the alias table overlap.

Images