Systems and methods for reducing instruction code memory footprint for multiple processes executed at a coprocessor

A processing system includes a first processor couplable to a first memory and a second memory. In response to a page migration trigger for a page in the first memory, the first processor is configured to, responsive to the page being a read-only page storing code for execution, initiate migration of the page to a code cache portion of a second memory associated with a second processor and shared by multiple processes executing at the second processor, and to configure each process of a set of processes executing at the second processor to access and execute the code from the code cache portion.

BACKGROUND

Conventional processing systems utilize page migration to take advantage of spatial locality between source and destination memory locations in the processing system. Page migration refers to the transferring of a page from a source memory location to a destination memory location that is closer in proximity to the processor that executes processes that utilize the pages stored in the destination memory location. Using page migration allows the processing system to reduce the amount of time taken to access pages in memory. However, current processing systems migrate pages between source and destination memory locations indiscriminately without taking into account characteristics of the pages themselves, which often leads to inefficient page migrations and duplication of scarce physical memory resources.

DETAILED DESCRIPTION

FIGS.1-4illustrate embodiments of a processing system that utilizes a read-only executable-shareable page migration scheme. The read-only-executable-shareable page migration scheme utilizes read-only executable and shareable characteristics of a page to migrate the page from a first memory to a second memory. In some embodiments, the first memory is a central processing unit (CPU) memory (hereinafter also referred to as “CPU memory”) primarily associated with a first processor (hereinafter also referred to as “CPU”)) and the second memory is a graphics processing unit (GPU) memory (hereinafter also referred to as “GPU memory”) primarily associated with a second processor or coprocessor (hereinafter also referred to as “GPU”). A migration controller located in, for example, a driver executed at the first processor or an operating system of the processing system, determines whether a page being requested for migration is a read-only-executable-shareable page or a non-read-only-executable-shareable page. The read-only-executable-shareable page is a page that represents read-only code for execution that is shareable by multiple processes executing on the coprocessor. A non-read-only-executable-shareable page is a page that does not represent shareable read-only code for execution and generally includes data buffers used by applications executing on the GPU for computing purposes. When the migration controller determines that the page is a non-read-only-executable-shareable page, the page is migrated to a non-read-only memory pool located in the coprocessor memory. When the migration controller determines that the page is a read-only-executable-shareable page, the page is migrated to a read-only-executable-shareable code cache located in coprocessor memory. The read-only-executable-shareable-code cache differs from other caches in that, for example, the read-only-executable-shareable code cache only stores pages that are read-only, executable, and shareable by multiple processes executing on the coprocessor. As the read-only-executable-shareable pages are migrated to the read-only-executable-shareable code cache, migration controller configures the multiple processes to reference the read-only-executable-shareable code cache when accessing the read-only-executable-shareable pages, instead of the non-read-only-executable-shareable code cache. As a result of having read-only-executable-shareable pages located in a read-only-executable-shareable code cache in the coprocessor memory, multiple processes executing on the coprocessor are able to share the read-only-executable-shareable pages that are located in the read-only-executable-shareable code cache, rather than having the first processor repeatedly allocate different memory space of the coprocessor memory for the same executable code contained in the read-only-executable-shareable pages to each process and thereby wasting valuable space in coprocessor memory.

In addition to migrating the read-only-executable-shareable pages to a read-only-executable-shareable code cache, during the read-only-executable-shareable page migration process, the migration controller monitors the size of the coprocessor code cache relative to the size of the plurality of read-only-executable-shareable pages that have been migrated to the read-only-executable-shareable code cache (read-only code cache). When the size of the plurality of read-only-executable-shareable pages reaches a specified threshold (e.g., a specified maximum storage capacity of the coprocessor code cache), the migration controller increases the size of the read-only-executable-shareable code cache or evicts cold pages (e.g., pages that have not been recently used by the processing system) from the read-only-executable shareable code cache to account for the increased size of the plurality of read-only-executable-shareable pages.

Thus, in some embodiments, in addition to being able to dynamically adjust the size of the read-only code cache, the migration controller is able to identify whether a page to be migrated includes read-only code that is executable and shareable by multiple processors at a coprocessor. After the migration controller identifies if the page is read-only code that is executable and shareable, migration controller migrates the read-only code to a read-only cache code region in the coprocessor's memory that is designated as accessible my multiple processes. The migration controller configures one or more processes to refer to the page's location in the read-only cache code region so that the multiple processes execute the code contained therein, which results in only one copy of the code needing to be stored in the memory, rather than a separate copy for each process.

For ease of illustration, the following description refers frequently to implementations of a coprocessor as a GPU. However, the present disclosure is not limited to this example context, but instead is applicable to any of a variety of coprocessors, including application-specific integrated circuits (ASICs) for machine learning and artificial intelligence applications, and the like, using the guidelines provided herein. As such, reference to a GPU as the coprocessor also applies to other types of coprocessors unless explicitly indicated.

FIG.1illustrates a block diagram of a processing system100that utilizes read-only-executable-shareable page migration in accordance with some embodiments. Processing system100includes system on chip (SoC)105coupled to memory150. SoC105can also be referred to as an integrated circuit (IC).

In one embodiment, SoC105includes a CPU165, input/output (I/O) interfaces155, caches160-1and160-2, fabric120, graphics processing unit (GPU)130, GPU memory110, and memory controller(s)140. While the SOC105is one example embodiment, in other embodiments the GPU130and/or the GPU memory110are implemented off-chip. For ease of illustration, SoC105includes other well-known components omitted fromFIG.1.

CPU165includes processing units175-1-N and a driver199. Processing units175-1-N are representative of any number and type of processing units, such as CPU cores, digital signal processing (DSP) cores, and the like. Processing units175-1-N of CPU165are coupled to caches160-1and160-2and fabric120. In some embodiments, CPU165executes the driver199implemented as a set of executable instructions stored in memory150. In some embodiments, driver199is implemented as part of an operating system (OS)191executed by the CPU165, as a driver for controlling operation of the GPU130, and the like. In one embodiment, driver199includes a migration controller198for controlling at least a part of the read-only-executable-shareable page migration scheme described in greater detail below.

In some embodiments, processing system100is a computer, laptop, mobile device, server or any of various other types of processing systems or devices. It is noted that the number of components of processing system100and/or SoC105can vary from embodiment to embodiment. There can be more or fewer of each component/subcomponent than the number shown inFIG.1. For example, in another embodiment, SoC105can include multiple memory controllers coupled to multiple memories. It is also noted that in some embodiments, processing system100and/or SoC105includes other components not shown inFIG.1. Additionally, in other embodiments, processing system100and SoC105is structured in other ways than shown inFIG.1.

In one embodiment, processing units175-1-N are configured to execute instructions of a particular instruction set architecture (ISA). Each processing unit175-1-N includes one or more execution units, cache memories, schedulers, branch prediction circuits, and so forth. In one embodiment, the processing units175-1-N are configured to execute the main control software of processing system100, such as an operating system. Generally, software executed by processing units175-1-N during use can control the other components of processing system100to realize the functionality of processing system100described herein. Processing units175-1-N can also execute other software, such as application programs.

GPU130includes at least memory controllers136, cache(s)138, translation lookaside buffer (TLB)149, and compute units145-1-N. Compute units145-1-N are representative of any number and type of compute units that are used for graphics or general-purpose processing. Each compute unit145-1-N includes any number of execution units, with the number of execution units per compute unit varying from embodiment to embodiment. In one embodiment, GPU130is configured to execute graphics pipeline operations such as draw commands, pixel operations, geometric computations, and other operations for rendering an image to a display. In another embodiment, GPU130is configured to execute operations unrelated to graphics. In a further embodiment, GPU130is configured to execute both graphics operations and non-graphics related operations. GPU130is coupled to fabric120and GPU memory110.

In one embodiment, GPU memory110is implemented using high-bandwidth memory (HBM). GPU memory110includes read-only-executable-shareable code cache102(also referred to as read-only code cache102), non-read-only-executable-shareable page memory pool111(also referred to as non-read only memory pool111), page table193, and page table195. In some embodiments, read-only code cache102is a cache that is configured to store read-only-executable-shareable pages. The read-only-executable-shareable pages are migrated from, for example, CPU memory163. Read-only code cache102is unique compared to other caches in that read-only code cache102only stores read-only-executable-shareable pages that are shared amongst multiple processes that are executed on GPU130.

I/O interfaces155are coupled to fabric120, and I/O interfaces155are representative of any number and type of interfaces (e.g., peripheral component interconnect (PCI) bus, PCI-Extended (PCI-X), PCIE (PCI Express) bus, gigabit Ethernet (GBE) bus, universal serial bus (USB)). Various types of peripheral devices can be coupled to I/O interfaces155. Such peripheral devices include (but are not limited to) displays, keyboards, mice, printers, scanners, joysticks or other types of game controllers, media recording devices, external storage devices, network interface cards, and so forth.

SoC105is coupled to memory150, which includes one or more memory modules. Each of the memory modules includes one or more memory devices mounted thereon. In some embodiments, memory150includes one or more memory devices mounted on a motherboard or other carrier upon which SoC105is also mounted. In one embodiment, memory150is used to implement a random access memory (RAM) for use with SoC105during operation. In different embodiments, the RAM implemented is static RAM (SRAM), dynamic RAM (DRAM), Resistive RAM (ReRAM), Phase Change RAM (PCRAM), or any other volatile or non-volatile RAM, or a combination thereof. The type of DRAM that is used to implement memory150includes (but is not limited to) double data rate (DDR) DRAM, DDR2 DRAM, DDR3 DRAM, and the like. Although not explicitly shown inFIG.1, in some embodiments SoC105includes one or more cache memories that are internal to the processing units175-1-N and/or compute units145-1-N (e.g., level 1 (L1) caches). In some embodiments, SoC105includes caches160-1- and160-2that are utilized by processing units175-1-N. In one embodiment, caches160-1and160-2are part of a cache subsystem including a cache controller.

It is noted that the letter “N” when displayed herein next to various structures is meant to generically indicate any number of elements for that structure (e.g., any number of processing units175-1-N in CPU165, including one processing unit). Additionally, different references withinFIG.1that use the letter “N” (e.g., compute units145-1-N) are not intended to indicate that equal numbers of the different elements are provided (e.g., the number of processing units175-1-N in CPU165can differ from the number of compute units145-1-N of GPU130).

In some embodiments, a memory management unit (not shown) includes a translation lookaside buffer (TLB)149. The memory management unit manages which translations are stored in TLB149based on memory access requests made to, for example, GPU memory110. The TLB149caches virtual-to-physical memory address translations. A larger set of virtual-to-physical address translations are stored in page tables (e.g., page tables193,194, and195). In some embodiments, more specifically, the page tables193,194, and195cache the virtual-to-physical memory address translations for the virtual addresses and physical addresses that correspond to read-only code cache102. In some embodiments, the memory management unit transfers virtual-to-physical address translations from the page tables (or a higher level of cache than TLB149) into TLB149upon a determination that such translations are likely to be used.

In some embodiments, during operation, page migration is initiated in processing system100using a page migration trigger, such as, for example, a memory access or other action such as operating system191determining that a page is going to be used in the near future. In some embodiments, operating system191is triggered to initiate the page migration by a memory access request from, for example, GPU130. For example, GPU130requests access to a page188stored in CPU memory163and, in response, operating system191determines that a page migration of the requested page188is to be performed for the memory access request. In some embodiments, the operating system191is notified of the access through, for example, a page fault on the GPU130.

In order to determine the storage location of the page to be migrated (e.g., page188that is to be migrated from CPU memory163to either read-only-executable-shareable code cache102or non-read-only memory pool111), migration controller198utilizes read-only executable and shareable characteristics of the page188that is to be migrated from CPU memory163to GPU memory110. The migration controller198that is located in driver199of CPU165determines whether the page188being requested for migration is a read-only-executable-shareable page or a non-read-only-executable-shareable page. That is, migration controller198identifies whether a page188to be migrated from CPU memory163to GPU memory110contains read-only code that is executable and shareable by multiple processes executing on GPU130.

In some embodiments, migration controller198identifies or determines whether page188is a read-only-executable-shareable page or a non-read-only-executable-shareable page by assessing a read-only, execute-only, and shareable-only characteristic of the page that is being migrated. That is, in some embodiments, each page is labeled as an execute-only, read-only, or shareable-only. In some embodiments, indication of a page as an execute-only, read-only, shareable-only occurs using a single bit or plurality of bits located on, for example, a page indicator on the page of being migrated. In some embodiments, in response to the migration controller198identifying that page188is a non-read-only-executable-shareable page, i.e., when migration controller198determines page188is a non-read-only-executable-shareable page, page188is migrated to non-read-only memory pool111located in the GPU memory110.

In response to the migration controller198identifying that page188is a read-only-executable-shareable page, instead of being migrated to non-read-only memory pool111, page188is migrated to a read-only code cache102located in GPU memory110that is designated as accessible by multiple processes executing on GPU130. More specifically, operating system191uses migration controller198to initiate migration of page188from CPU memory163to read-only code cache102. The transfer of page188from CPU memory163to read-only code cache102involves moving page188to read-only code cache102, configuring the one or more processes to refer to the page's location in the read-only cache102, and providing a notification signal to the other processes that utilize updated page table that the virtual-to-physical mapping has been updated (i.e., issuing TLB shootdowns). To move page188to the read-only code cache102, operating system191transmits a request to CPU memory163to copy page188from CPU memory163to read-only code cache102. Operating system191then copies page188from CPU memory163to read-only code cache102. Operating system191transmits a request to configure the mapping(s) for page188in the page table193, page table195, and page table194.

In order to configure the one or more processes executing on GPU130to refer to page188's location in read-only code cache102, page table193(corresponding to a first process) and page table195(corresponding to a second process) are updated to map the virtual addresses in the virtual address spaces of each process that correspond to the read-only-executable-shareable page188to the physical address in read-only code cache102. Since page188has been moved from CPU memory163, page table194of CPU memory163is also updated with the physical location of the transferred page188. The update to page tables193and195modifies the virtual-to-physical address translation(s) for the page188(or pages when a plurality of pages are being migrated) to point to the destination physical address in read-only code cache102for the migrated page instead of the source physical address for the migrated page.

In some embodiments, during the migration process (i.e., the migration of page188from CPU memory163to read-only code cache102), migration controller198monitors the size of the read-only code cache102relative to the size of the plurality of read-only-executable-shareable pages that have been migrated to the read-only code cache102. If migration controller198determines that read-only code cache102is at or close to maximum capacity (e.g., by determining that the total number of pages cached at the read-only code cache102meets or exceeds a specified threshold), operating system191uses migration controller198to dynamically adjust the size of the read-only code cache102to increase the amount of memory available for additional pages (e.g., for additional pages188). In some embodiments, if migration controller198determines that read-only code cache102is at maximum capacity, operating system191selects pages from read-only code cache102that are to be evicted. For example, operating system191evicts “cold pages” from read-only code cache102, where cold pages are pages that have not been recently accessed (e.g., pages that haven't been accessed in a specific amount of time, as measured by, for example, a specified number of clock cycles or a specified number of accesses to the read-only code cache102). Thus, when the size of the plurality of read-only-executable-shareable pages reaches a read-only code cache maximum threshold, migration controller198either increases the size of the read-only code cache102or evicts cold pages from the read-only code cache102to account for the storage of the additional migrated read-only-executable-shareable page188(or both).

After page188has been migrated to read-only code cache102, the migrated page188is available for shared use by the plurality of processes that are executing on GPU130. For example, as described below with reference toFIG.2A, in some embodiments, two or more processes executing on GPU130have individual virtual address spaces that point to the shared code (e.g., the read-only-executable-shareable pages) that has been migrated to read-only code cache102. Having multiple processes utilize the shared code reduces memory access latencies since the shared code does not have to be loaded for each individual process. As stated previously, because the read-only-executable-shareable pages are available for shared use by the plurality of processes executing on GPU130, operating system191is not required to re-load the read-only-executable-shareable pages that have been transferred to read-only code cache102.

FIG.2Aillustrates a shared code mapping200of the read-only-executable-shareable page migration scheme implemented inFIG.1. Shared code mapping200depicts the virtual address spaces (virtual address space277and virtual address space278) of a plurality of processes (process1and process2) executing on GPU130that are mapped to a single read-only-executable-shareable code299. In some embodiments, with further reference toFIG.1, the read-only-executable-shareable code299includes a plurality of read-only-executable-shareable code pages188. Using, for example, page table193for virtual-address-to-physical-address translations for the first process and page table195for virtual-address-to-physical translations for the second process, each virtual address space is mapped to the same single read-only-executable-shareable code299, preventing the migration controller198from having to transfer multiple copies of the same code for execution by process1and process2. As stated previously, the update to page tables193and195has allowed the virtual-to-physical address translations for the read-only-executable-shareable code299(a page or plurality of pages of read-only-executable-shared code) to point to the destination physical address in read-only code cache102.

FIG.2Bis a block diagram illustrating a portion of the processing system100ofFIG.1in greater detail in accordance with some embodiments. The portion of the processing system100depicted inFIG.2Bincludes GPU memory110and CPU memory163.FIG.2Bdepicts a portion of GPU virtual address space230that includes “hot” read-only-executable-shareable pages232and233(e.g., pages that have been recently used by the processing system100) and cold-read-only-executable-shareable pages242and243(e.g., pages that have not been recently used by the processing system100) that correspond to, for example, shader code that is to be read and executed by processes executing on GPU130. As depicted, the hot read-only-executable-shareable pages232and233are mapped in page table193to read-only code cache102. The cold read-only-executable-shareable pages242and243are mapped to CPU memory163. In response to a page fault to page table193that is triggered by a memory access to the cold read-only-executable-shareable pages242and243, the cold read-only-executable-shareable pages242and243are migrated from CPU memory163to read-only code cache102of GPU memory110as described with reference toFIG.3below.

FIG.3is a flow diagram of a method300for migrating memory pages using read-only-executable-shareable page migration. Although described with respect to the system shown and described with respect toFIGS.1-2, it should be understood that any system configured to perform the method, in any technically feasible order, falls within the scope of the present disclosure.

As depicted, the method300commences at block305with the OS191triggering a page migration. In some embodiments, as stated previously, the trigger can be a memory access or another action, such as, for example, operating system191determining that page188(or pages) should be migrated from CPU memory163to GPU memory110according to predicted future use of the page188. At block310, migration controller198identifies or determines whether the page188to be migrated is a read-only-executable-shareable page or a non-read-only-executable-shareable page. The determination of whether the page to be migrated is a read-only-executable-shareable page or a non-read-only-executable-shareable page involves, for example, assessing a bit-configuration located in the page to be migrated that indicates whether the page is a read-only page, shareable-only page, and/or executable-only page.

At block315, when migration controller198determines that the page is not a read-only-executable-shareable page at block310, the page is migrated to non-read only memory pool111. At block325, the multiple processes executing on GPU130access the non-read-only-executable-shareable pages individually from non-read only memory pool111. That is, the non-read-only-executable-shareable pages are not shared amongst the multiple process executing on GPU130.

At block320, when migration controller198determines that the page is a read-only-executable-shareable page at block310, the page is migrated to read-only code cache102. At block330, the page tables (e.g., page table193, page table195, and page table194) are updated with the updated physical address of the page (or pages for a plurality of pages) that has been migrated. At block340, the read-only-executable-shareable page that has been migrated to read-only code cache102is designated or identified as a shared read-only-executable-shareable page. In some embodiments, the designation of the page as a read-only-executable-shareable page is by way of a bit embedded in the page that is set to indicate that the page is a read-only-executable-shareable page. At block350, the read-only-executable-shareable page is shared amongst the plurality of processes that are executing on GPU130. For example, during a read request by a process executing on GPU130, the read-only executable code on the read-only-executable-shareable page or read-only-executable-shareable pages is available for execution by the one or more processes executing on GPU130. That is, in some embodiments, both the virtual address space of a first process executing on GPU130and the virtual address space of a second process executing on GPU130are mapped using page table193and page195to the same read-only-executable-shareable pages (e.g., read-only GPU code) stored in the read-only code cache102. As a result, the read-only-executable-shareable page migration scheme able to optimize instruction memory footprint for multiple processes that share, for example, the same shader code, by mapping the same physical code pages to the virtual address space of each process without duplicating physical memory. In some embodiments, the read-only-executable-shareable page migration scheme reduces the memory footprint when sharing code between multiple processes by sharing the read-only portions of a GPU executable among the plurality of processes executing on, for example, GPU130. In some embodiments, the memory footprint is reduced by a factor of N, where N is the number of processes sharing the GPU130and executing the same code represented by the read-only-executable-shareable pages that have been migrated to read-only code cache102.

FIG.4is a flow diagram of a method400for adjusting the size of read-only code cache102during read-only-executable-shareable page migration. Although described with respect to the system shown and described with respect toFIGS.1-3, it should be understood that any system configured to perform the method, in any technically feasible order, falls within the scope of the present disclosure.

As depicted, the method400commences at block410, where migration controller198determines whether the size of the read-only-executable-shareable pages that have been stored in read-only code cache102is equal to the read-only code cache threshold (e.g., a maximum capacity of the read-only code cache102). In some embodiments, the threshold is set by the user of the processing system100. In some embodiments, the threshold is represented as a fixed memory capacity or as a percentage of the total memory capacity of the read-only code cache102.

In some embodiments, at block410, when the size of the number of read-only-executable-shareable pages stored in read-only code cache102is equal to the read-only code cache threshold, at block420, migration controller198determines whether to increase the size of the read-only code cache102, or evict the read-only-executable-shareable pages from the read-only code cache102. In some embodiments, the user of processing system100dictates to migration controller198whether to increase the size of the read-only code cache102or evict the read-only-executable-shareable pages from the read-only code cache102. In addition, in some embodiments, the user of processing system100dictates the amount of memory by which to increase the size of the read-only code cache102and the number of cold read-only-executable-shareable pages to evict.

At block430, when migration controller198determines to increase the size of the read-only code cache102at block420, migration controller198increases the size of the read-only code cache102to account for additional read-only-executable-shareable pages that are to be stored in read-only code cache102. At block440, migration controller198copies the read-only-executable-shareable page into the size adjusted read-only-code cache102.

Turning to block450, when migration controller198determines not to increase the size of the read-only code cache102at block420, migration controller198evicts read-only-executable-shareable pages from the read-only code cache102. In some embodiments, migration controller198evicts cold read-only-executable-shareable pages from read-only code cache102, but the user of processing system100can program migration controller198to evict read-only-executable-shareable pages from read-only code cache102for other reasons. At block460, the read-only-executable-shareable page is copied into the page evicted read-only code cache102.

Returning back to block410, when the size of the number of read-only-executable-shareable pages stored in read-only code cache102is not equal to the read-only code cache threshold, at block470, migration controller198allows the size of read-only code cache102to remain unchanged for further storage of migrated read-only-executable-shareable pages. At block480, migration controller198copies the read-only-executable-shareable page to the unadjusted read-only code cache102.

In various embodiments, a method includes, in response to a page migration trigger for a page present in a first memory associated with a first processor, responsive to the page being a read-only page storing code for execution, migrating the page to a code cache portion of a second memory associated with a second processor and shared by multiple processes executing at the second processor, and configuring each process of a set of processes executing at the second processor to access and execute the code from the code cache portion. In some embodiments, the method further includes, responsive to the page not being the read-only page storing code for execution, migrating the page to a non-code cache portion of the second memory. In some embodiments, the method further includes, identifying whether the page is the read-only page storing code for execution by using a page indicator indicative of whether the page is the read-only page, an execute-only page, or a read-write page.

In some embodiments of the method, migrating the page to a code cache portion includes, copying the read-only page to the code cache portion, updating a page table of a plurality of page tables with a virtual-address-to-physical-address mapping of the read-only page, and providing a notification signal to the multiple processes that indicates that the virtual-address-to physical address mapping of the read-only page has been updated. In some embodiments of the method, updating the page table includes inserting a page table entry into the page table of the second memory in response to the migration of the page into the code cache portion. In some embodiments, the method further includes creating a read-only mapping in a virtual address space of a first process of the multiple processes, wherein the read-only mapping occurs after text relocations in the read-only page. In some embodiments, the method further includes, in response to a code cache threshold assessment, determining whether to a adjust a maximum size of the code cache portion or evict at least a currently cached read-only page from the code cache portion. In some embodiments of the method, the first processor is a central processing unit (CPU) and the second processor is a graphical processing unit (GPU). In some embodiments of the method, the first processor is a central processing unit (CPU) and the second processor is an application-specific integrated circuit (ASIC).

In some embodiments, a processing system includes a first processor couplable to a first memory and a second memory, wherein in response to a page migration trigger for a page in the first memory, the first processor is configured to, responsive to the page being a read-only page storing code for execution, initiate migration of the page to a code cache portion of a second memory associated with a second processor and shared by multiple processes executing at the second processor, and to configure each process of a set of processes executing at the second processor to access and execute the code from the code cache portion.

In some embodiments of the processing system, responsive to the page not being the read-only page storing code for execution, the page is migrated by the first processor to a separate portion of the second memory. In some embodiments of the processing, a page indicator, indicative of whether the page is the read-only page, an execute-only page, or a read-write page, is used to identify whether the page is the read-only page storing code for execution.

In some embodiments of the processing system, the migration of the page to a code cache portion includes the read-only page being copied to the code cache portion, a page table of a plurality of page tables being updated with a virtual-address-to-physical-address mapping of the read-only page, and a notification signal is provided to the multiple processes that indicates that the virtual-address-to physical address mapping of the read-only page has been updated. In some embodiments of the processing system, a page table entry of the page table is used to map a virtual address of the page to a physical address in a page table of the code cache portion. In some embodiments of the processing system, a read-only mapping is created in a virtual address space of a process of the multiple processes, wherein the read-only mapping occurs after text relocations in the read-only page.

In some embodiments of the processing system, in response to a code cache threshold assessment, the first processor determines whether to adjust a maximum size of the code cache portion or evict at least a currently cached read-only page from the code cache portion. In some embodiments of the processing system, the first processor is a central processing unit (CPU) and the second processor is a graphical processing unit (GPU).

In some embodiments, a method includes migrating a plurality of read-only pages from a first memory associated with a first processor to a code cache of a second memory associated with a second processor, the code cache being used to store read-only pages that are shareable, executable, and accessible among a plurality of processes executing on the second processor, monitoring a size of the code cache relative to a size of the plurality of read-only pages, and in response to the size of the plurality of read-only pages being greater or equal to a code cache threshold, increasing the size of the code cache to account for the increase in size of the plurality of read-only pages or evicting a plurality of cold read-only pages from the code cache.

In some embodiments, the method further includes, in response to the size of the plurality of read-only pages not being greater or equal to the code cache threshold, keeping the size of the code cache unchanged. In some embodiments, the method further includes migrating a plurality of non-read-only pages to a non-read-only code cache.