Patent Description:
In recent years, processors have been developed to execute an increasing number of floating point operations per second (FLOPS). Design improvements that contribute to increased FLOPS include, but are not limited to, greater transistor density and multiple cores. As additional transistors and/or cores are added to processors, a corresponding increase in power consumption and heat occurs, which may become counterproductive to FLOPS performance.

<CIT> relates to a processor system comprising a processor and at least a first memory and a second memory. The means for memory allocation perform a periodically static allocation of data into the first memory. The means for memory allocation are run-time updateable by software. An execution profiling section is provided for continuously or intermittently providing execution data used for updating the means for memory allocation. Memory allocation is performed on a variable or record level.

<CIT> describes a method for memory management for a mobile multimedia processor. The method comprises receiving within a mobile multimedia processor chip a plurality of memory requests. The plurality of memory requests are handled by allocating memory from at least one on-chip memory block and/or at least one off-chip memory block. The memory is allocated based on a priority level of each of the plurality of memory requests and at least one dynamically settable global memory allocation priority threshold.

In the following description, any embodiment referred to and not falling within the scope of the claims is merely an example useful to the understanding of the invention.

Methods, articles of manufacture, and apparatus are disclosed to manage workload memory allocation. An example method includes identifying a primary memory and a secondary memory associated with a platform, the secondary memory having first performance metrics different from second performance metrics of the primary memory, identifying access metrics associated with a plurality of data elements invoked by a workload during execution on the platform, prioritizing a list of the plurality of data elements based on the access metrics associated with corresponding ones of the plurality of data elements, and reallocating a first one of the plurality of data elements from the primary memory to the secondary memory based on the priority of the first one of the plurality of memory elements.

<FIG> is a schematic illustration of an example workload controller <NUM> to control workload memory allocation. In the illustrated example of <FIG>, the workload manager <NUM> includes a workload manager <NUM>, a data element identifier <NUM>, a data element tracker <NUM>, a data element performance calculator <NUM>, a memory manager <NUM><NUM>, a code modifier <NUM><NUM>, and a linker interface <NUM>. The example workload manager <NUM> is communicatively connected to an example platform <NUM> having one or more workloads <NUM><NUM>, a primary memory <NUM>, a secondary memory <NUM>, and a processor <NUM>.

The example processor <NUM> of the platform <NUM> of <FIG> includes any number of cores to execute the example workload <NUM><NUM>. The example workload <NUM> of <FIG> may include, but is not limited to one or more programs of executable code (e.g., a binary) generated and linked by a compiler mechanism from source code. The execution of code may include, but is not limited to executing one or more programs, programs having any number of associated dynamic link libraries (DLLs), one or more separate files linked together to the same program, and/or a cluster usage model in which a workload includes a program with any number of shared libraries involving one or more processes. During execution of the example workload <NUM>, the processor <NUM> may access the primary memory <NUM> to manipulate and/or otherwise process data. Data may include, but is not limited to, data arrays, files, heap and/or stack. As used herein, references to data, array data and/or data arrays include all types of data that may be processed by the processor <NUM> and/or stored in primary memory <NUM> and/or secondary memory <NUM>. As used herein, primary memory <NUM> includes flash memory, read-only memory (ROM), random access memory (RAM) and/or a hard disk drive memory. Primary memory <NUM> may include, for example, any type of double data rate (DDR) RAM (e.g., DDR2, DDR3, DDR4, etc.).

In some examples, the secondary memory <NUM> of the platform <NUM> includes an enhanced performance design that exhibits a lower latency, coherency, and/or a higher bandwidth capability when compared to the primary memory <NUM>. The example secondary memory <NUM> may include flash memory, ROM, RAM and/or hard disk drive memory having improved performance metric(s) when compared to corresponding flash memory, ROM, RAM and/or hard disk drive memory corresponding to the example primary memory <NUM>. The example secondary memory <NUM> may have an associated cost premium based on its improved performance characteristics and, thus, a corresponding size/capacity of the secondary memory <NUM> may be substantially lower than that of the primary memory <NUM>. Additionally, utilization of the example secondary memory <NUM> is scrutinized because of its relatively higher cost and lower size. The example secondary memory <NUM> may include, but is not limited to scratchpad RAM. Scratchpad RAM is a relatively high-speed internal memory, may be coherent, and may be located on the processor <NUM>, near the processor <NUM> and/or within processor packaging.

In operation, the example workload manager <NUM> identifies one or more opportunities to improve (e.g., optimize) code that is executed on the example platform <NUM>. As described above, although additional transistors and/or cores added to the processor <NUM> may yield faster results when executing code, the corresponding heat generation and/or power consumption of the added transistors may eventually provide diminishing returns in FLOPS performance. To improve platform performance when executing one or more workloads <NUM>, the example workload manager <NUM> identifies memory utilization patterns of the workload <NUM>. In the event a first data array that is created and/or otherwise manipulated by the example processor <NUM> exhibits a relatively high demand (e.g., a number of read/write operations when compared to a second data array, a degree to which the data array materially impacts workload/platform performance, relative comparisons, etc.), the example workload manager <NUM> modifies code associated with the example workload <NUM> to utilize a relatively faster type of memory for such read/write operations. Code modification performed by the example workload manager <NUM> may include, but is not limited to source code modification, binary modification, dynamic just-in-time (JIT) compiler modification, etc. In some examples, code may be re-linked without one or more compilation operations to, in part, improve speed. The faster type of memory, such as the example secondary memory <NUM>, allows read/write operations to occur with lower latency and/or a higher bandwidth than the primary memory <NUM>, thereby improving the performance of the workload <NUM> when executing on the example platform <NUM>.

The example workload manager <NUM> retrieves and/or otherwise receives a workload <NUM> from the platform <NUM> and executes the workload in a monitored environment to characterize its operation. In some examples, the workload manager <NUM> obtains, retrieves and/or otherwise obtains information associated with the example platform <NUM>, such as one or more type(s) of memory utilized and/or otherwise available to the platform <NUM>. As described in further detail below, in the event that the platform <NUM> includes one or more types of memory having improved operating characteristics (e.g., the secondary memory <NUM>) when compared to the example primary memory <NUM>, then the example workload manager <NUM> modifies code (e.g., source code, one or more binaries, binaries on a disk to facilitate subsequent execution optimization, etc.) associated with the workload <NUM> to utilize such memory in an effort to improve platform performance. The example workload manager <NUM> may invoke the workload <NUM> one or more times to characterize its data array and memory utilization behavior. In some examples, the workload manager <NUM> invokes a number of execution iterations of the workload <NUM> to determine average characteristics. In other examples, the workload manager <NUM> invokes the workload <NUM> with one or more input parameters to identify corresponding data array and/or memory utilization behavior (e.g., stress test).

During execution of the example workload <NUM>, the example data element identifier <NUM> identifies instances of data access to one or more memories of the platform <NUM>, such as the example primary memory <NUM>. The example data element tracker <NUM> counts a number of detected instances of data access for each data array employed by the example workload <NUM>, and stores such counts for later analysis of the workload <NUM> behavior. In other examples, collecting and/or monitoring access counts may be insufficient to determine a relative grading of the data array of interest when compared to one or more other data arrays. In such cases, collecting and/or monitoring accesses per unit of time for each data array of interest allows for a relative grading of which data array(s) may contribute the greatest benefit for platform and/or workload performance. As described above, each data array may include any type of memory structure employed by the example workload, such as arrays, files, heaps, stacks, registers, etc. The example data element tracker <NUM> may also collect intelligence from the workload to send to the example data element performance calculator <NUM>.

The example data element performance calculator <NUM> analyzes the stored instances of data access and generates a table of one or more data access behaviors associated with each data array performing one or more read/write operations to a memory. As described in further detail below, the table generated by the example data element performance calculator <NUM> may include a count of the number of memory access attempts (access count) associated with each data array, a count of the number of instances where a memory access attempt results in delay (e.g., processor spin, processor waiting for a memory to become available for read/write operation(s), stalls associated with loads and/or stores), and/or a number of cycles that occur during instances where the memory access attempt(s) cause a processor spin (e.g., a processor wait event). Based on, in part, one or more count values identified by the example data element performance calculator <NUM>, the table of data access behaviors may rank (e.g., prioritize) each of the data arrays. In some examples, the rank (e.g., priority) is based on a number of data array access instances to memory, while in other examples the rank is based on a number of processor cycles that result from data array access instances to memory. Generally speaking, while a first data array may include a relatively greater number of access attempts to one or more memories (e.g., the primary memory <NUM>) when compared to a second data array, each memory access instance by the first data array may be associated with a relatively small amount of data transfer. As such, a relatively high count associated with the first data array may not be indicative of a candidate change (e.g., optimization) for improving platform <NUM> performance via reallocation of data array (e.g., a data element) usage of the primary memory <NUM> to the relatively faster secondary memory <NUM>. On the other hand, in some examples a relatively low count associated with the first data array may also be associated with a relatively large amount of data transfer during each access attempt. In such examples, a faster memory may be beneficial when configuring (e.g., optimizing) the platform <NUM> performance to reduce (e.g., minimize) and/or eliminate processor spin that may otherwise occur when relatively slow memory cannot perform read/writer operation(s) fast enough.

<FIG> illustrates an example table <NUM> generated by the example data element performance calculator <NUM>. In the illustrated example of <FIG>, the table <NUM> includes a data element column <NUM>, an access count column <NUM>, a wait count column <NUM> and a processor wait cycle count column <NUM>. The example data element column <NUM> includes a list of data arrays identified by the example data element identifier <NUM> that have participated in the example workload <NUM><NUM>. While the illustrated example of <FIG> includes arrays, methods, articles of manufacture and/or apparatus disclosed herein are not limited thereto. For example, other forms of memory may be realized including, but not limited to scratch memory, scratchpad(s), heaps, dynamically allocated data objects, stacks, etc. For each identified data array, the example table <NUM> includes a corresponding count value in the access count column <NUM> that is indicative of the number of times the data array has made an access attempt (e.g., read, write, etc.) to a memory of the platform <NUM><NUM>. Additionally, the example table <NUM> includes a corresponding count value in the wait count column <NUM> indicative of the number of times the data array access has caused a corresponding wait for the processor. For example, a first row <NUM> of the table <NUM> is associated with "Array <NUM>," which accessed memory <NUM> times, but none of those access instances caused any corresponding spin/wait for the processor <NUM>, as shown by the "<NUM>" in the example wait count column <NUM>. As such, the example "Array <NUM>" did not cause any corresponding cycle count of the example processor <NUM>, as shown by the "<NUM>" in the example processor wait cycle count column <NUM>.

On the other hand, an example third row <NUM> of the table <NUM> is associated with "Array <NUM>," and accessed memory <NUM>,<NUM> times in which <NUM> instances of memory access caused the example processor <NUM> to wait. The corresponding number of processor cycles caused by the <NUM> instances of processor <NUM> waiting is <NUM>,<NUM> (e.g., each of the <NUM> access attempts caused a delay of fifty processor cycles). An example fifth row <NUM> of the table <NUM> is associated with "Array <NUM>," and accessed memory <NUM>,<NUM> times in which <NUM>,<NUM> instances of memory access caused the example processor <NUM> to wait. While "Array <NUM>" accessed memory roughly half as many times as "Array <NUM>," the corresponding number of processor cycles caused by the <NUM>,<NUM> instances of processor <NUM> waiting during "Array <NUM>" memory accesses is <NUM> x <NUM><<NUM>>. Relatively speaking, the delay caused by "Array <NUM>" memory accesses is substantially greater than the one or more delays caused by other data arrays associated with the workload <NUM> and, thus, example "Array <NUM>" may be a candidate for use with the secondary memory <NUM>.

In some examples, data elements place memory access demands at one or more instances during execution of the example workload <NUM><NUM>. For example, a first data element (e.g., "Array <NUM>") may perform all of its memory access operations during the first half of the execution process associated with workload <NUM><NUM>, while the last half of the execution process does not include further access attempts to the first data element. The information associated with when data elements place demands on platform <NUM><NUM> memory may allow the example workload manager <NUM> to allocate memory usage in a manner that preserves the limited resources of the secondary memory <NUM>.

<FIG> illustrates an example data array profile table <NUM> generated by the data element performance calculator <NUM>. In the illustrated example of <FIG>, the table <NUM> includes a data element column <NUM> and an activity profile column <NUM>. The example data element performance calculator <NUM> generates a plot of memory access activity for each corresponding data element (e.g., "Array <NUM>" through "Array <NUM>") during the course of execution (e.g., workload start time <NUM> through workload stop time <NUM>) of the example workload <NUM><NUM>. During the course of execution (horizontal axis), each plot represents a relative magnitude of access activity with respect to other data elements. A first row <NUM> of the example table <NUM> is associated with data element "Array <NUM>" and indicates, with an activity profile <NUM>, that memory access activity occurs during the last three-fourths of workload execution. A third row <NUM> of the example table <NUM> is associated with data element "Array <NUM>" and indicates, with an activity profile <NUM>, memory access activity occurs during the first half of workload execution. Additionally, the memory access activity profile associated with "Array <NUM>" <NUM> is taller than the memory access activity profile associated with "Array <NUM>" <NUM>, which indicates a relative difference in the number of access attempts per unit of time for each data element. In some examples, each access activity profile height is compared against one or more thresholds indicative of a number of memory access instances during a period of time during workload <NUM> execution. Other example thresholds may be based on a number of processor cycles that occur during processor wait periods (spin) due to memory latency and/or bandwidth limitations. While the example thresholds may be based on express values, other example thresholds may be based on a relative percentage when compared to all of the data arrays active during workload <NUM> execution.

After the example workload <NUM> is executed and/or executed for a number of iterations to collect data array (and/or any other type of memory) behavior information (e.g., workload execution profiles, data element access counts, wait instance counts (e.g., processor wait), etc.), the example data element identifier <NUM> selects one of the data elements from the example data element column <NUM> of the table <NUM>. The example memory manager <NUM> determines a size of the example secondary memory <NUM> and a corresponding amount of remaining space of the secondary memory <NUM> that is unused. In the event that the selected data element under review is indicative of high demand throughout the duration of workload <NUM> execution, and there is enough remaining space in the example secondary memory <NUM>, then the example code modifier <NUM> flags the data element to use the secondary memory <NUM> during execution. In other examples, there may be temporal variations of memory use during the life of the workload. A threshold value may be used to determine whether the selected data element should utilize the secondary memory <NUM>. As described below, data elements that are flagged to use a specific memory, such as the faster secondary memory <NUM>, are later modified by the example code modifier <NUM>, compiled and/or linked to generate a new binary and/or modify an existing binary (e.g., without prior source code modification(s)).

However, in the event that the selected data element does not utilize memory and/or make memory access attempts throughout the duration of the workload <NUM> execution, then the example memory manager <NUM> determines whether the selected data element utilizes a threshold amount of memory resources during a portion of the workload <NUM> execution. In operation, the example memory manager <NUM> may analyze the activity profiles in the activity profile column <NUM> associated with the data element of interest to identify a threshold demand. For example, if the data element associated with "Array <NUM>" is analyzed by the memory manager <NUM><NUM>, the memory manager <NUM> may invoke the example code modifier <NUM><NUM> to modify code (e.g., source code, one or more binaries, etc.) to utilize secondary memory <NUM> for a first half of the workload <NUM>, and utilize primary memory <NUM> for a second half of the workload <NUM><NUM>. Splitting memory utilization throughout the duration of the example workload <NUM> may allow higher demand data elements to operate faster when needed, and relinquish such memory when no longer needed, as shown by each corresponding data element profile of <FIG>.

While an example manner of implementing the workload manager <NUM> has been illustrated in <FIG>, one or more of the elements, processes and/or devices illustrated in <FIG> may be combined, divided, re-arranged, omitted, eliminated and/or implemented in any other way. Further, the example workload manager <NUM>, the example workload manager <NUM>, the example data element identifier <NUM>, the example data element tracker <NUM>, the example data element performance calculator <NUM>, the example memory manager <NUM>, the example code modifier <NUM><NUM>, the example primary memory <NUM> and/or the example secondary memory <NUM> of <FIG> may be implemented by hardware, software, firmware and/or any combination of hardware, software and/or firmware. Thus, for example, any of the example workload manager <NUM>, the example workload manager <NUM>, the example data element identifier <NUM>, the example data element tracker <NUM>, the example data element performance calculator <NUM>, the example memory manager <NUM>, the example code modifier <NUM>, the example primary memory <NUM> and/or the example secondary memory <NUM> could be implemented by one or more circuit(s), programmable processsor(s), application specific integrated circuit(s) (ASIC(s)), programmable logic device(s) (PLD(s)) and/or field programmable logic device(s) (FPLD(s)), etc. When any of the apparatus or system claims of this patent are read to cover a purely software and/or firmware implementation, at least one of the example workload manager <NUM>, the example workload manager <NUM>, the example data element identifier <NUM>, the example data element tracker <NUM>, the example data element performance calculator <NUM>, the example memory manager <NUM>, the example code modifier <NUM>, the example primary memory <NUM> and/or the example secondary memory <NUM> are hereby expressly defined to include at least one tangible computer readable medium such as a memory, DVD, CD, BluRay, etc. storing the software and/or firmware.

Further still, the example workload manager <NUM> of <FIG> may include one or more elements, processes and/or devices in addition to, or instead of, those illustrated in <FIG>, and/or may include more than one of any or all of the illustrated elements, processes and devices.

A flowchart representative of example machine readable instructions for implementing the workload manager <NUM> of <FIG> is shown in <FIG>. In this example, the machine readable instructions comprise a program for execution by a processor such as the processor <NUM> shown in the example computer <NUM> discussed below in connection with <FIG>. The program may be embodied in software stored on one or more tangible computer readable medium(s) such as a CD-ROM, a floppy disk, a hard drive, a digital versatile disk (DVD), a BluRay disk, or a memory associated with the processor <NUM>, but the entire program and/or parts thereof could alternatively be executed by a device other than the processor <NUM> and/or embodied in firmware or dedicated hardware. Further, although the example program is described with reference to the flowchart illustrated in <FIG>, many other methods of implementing the example workload manager <NUM> may alternatively be used. For example, the order of execution of the blocks may be changed, and/or some of the blocks described may be changed, eliminated, or combined.

As mentioned above, the example processes of <FIG> may be implemented using coded instructions (e.g., computer readable instructions) stored on one or more tangible computer readable medium(s) such as a hard disk drive, a flash memory, a read-only memory (ROM), a compact disk (CD), a digital versatile disk (DVD), a cache, a random-access memory (RAM) and/or any other storage media in which information is stored for any duration (e.g., for extended time periods, permanently, brief instances, for temporarily buffering, and/or for caching of the information). As used herein, the term tangible computer readable medium is expressly defined to include any type of computer readable storage and to exclude propagating signals. Additionally or alternatively, the example processes of <FIG> may be implemented using coded instructions (e.g., computer readable instructions) stored on a non-transitory computer readable medium such as a hard disk drive, a flash memory, a read-only memory, a compact disk, a digital versatile disk, a cache, a random-access memory and/or any other storage media in which information is stored for any duration (e.g., for extended time periods, permanently, brief instances, for temporarily buffering, and/or for caching of the information). As used herein, the term non-transitory computer readable medium is expressly defined to include any type of computer readable medium and to exclude propagating signals. As used herein, when the phrase "at least" is used as the transition term in a preamble of a claim, it is open-ended in the same manner as the term "comprising" is open ended. Thus, a claim using "at least" as the transition term in its preamble may include elements in addition to those expressly recited in the claim.

The program <NUM> of <FIG> begins at block <NUM> in which the example workload manager <NUM> retrieves, obtains and/or otherwise receives the workload <NUM> from the platform <NUM>. The example workload <NUM> may be stored on a memory of the platform and may include one or more executable programs that utilize one or more resources of the example platform <NUM>. Any number of execution iterations may be invoked by the example workload manager <NUM> to characterize the behavior of the workload on the example platform <NUM> (block <NUM>). In some examples, the workload manager <NUM> invokes the workload <NUM> to execute once on the platform <NUM> when collecting one or more parameters indicative of data element behavior. In other examples, the workload manager <NUM> invokes the workload <NUM> to execute through a number of iterations to calculate average values of the one or more parameters indicative of data element behavior.

During execution of the example workload <NUM>, the data element identifier <NUM> identifies instances of data array access attempts to one or more memories of the platform <NUM>, such as data array(s) that attempt to access the primary memory <NUM> (block <NUM>). Generally speaking, some data arrays are invoked by the workload <NUM> infrequently and, thus, do not substantially contribute to workload <NUM> execution delay. In other examples, other data arrays that are invoked by the workload <NUM> make relatively frequent attempts at memory access (e.g., read/write access attempts), thereby potentially contributing to overall workload <NUM> execution time to a greater extent. To identify a degree with which data arrays interact with platform <NUM> memory, the example data element tracker <NUM> gathers performance information, such as, but not limited to counting a number of instances each data array makes a memory access request and/or identifying processor stalls (block <NUM>). Counting data access instances may include, but is not limited to, employing a performance monitoring unit (PMU) to gather data from one or more model specific registers (MSRs). The MSRs may include counter registers, event programming registers and/or global event registers. Additionally, the PMU may perform event based sampling to count events related to processor activity, such as instances where the processor waits for memory availability caused by, for example, memory latency and/or memory bandwidth limitations. In some examples, sampling may occur in response to perturbation of the workload to appreciate the effect(s) of one or more forced input(s) to the workload and/or platform.

While the example workload <NUM> of interest executes on the example platform <NUM> (block <NUM>), control returns to blocks <NUM> and <NUM> any number of times to identify data access instances and count a number of times each data array makes a memory access attempt. When execution of the example workload <NUM> of interest is complete (block <NUM>), the example data element performance calculator <NUM> generates a table (e.g., the table <NUM> of <FIG>) of the collected parameters (block <NUM>). The collected parameters may include, but are not limited to a list of data arrays that have made one or more access attempts to memory, a count of how many times each data array makes an access attempt to memory during the workload <NUM> execution, a count of how many times an access attempt by the data array causes a corresponding delay (e.g., wait instances, a processor spin, cause processor to wait on memory that is not finished with a prior read/write operation), and/or a count of a number of processor cycles that elapse during the workload <NUM> execution while the processor is waiting for access to the memory (e.g., the primary memory <NUM>). While the example table <NUM> (see <FIG>) is described herein as being created by the example data element performance calculator <NUM>, any other type of workload profile representation may be generated including, but not limited to a heatmap of data array memory access activity. Additionally, the example data element performance calculator <NUM> generates an example data array profile table <NUM> (see <FIG>) to identify a temporal indication of data array memory access during execution of the workload <NUM> (block <NUM>) as described in further detail below.

To determine whether one or more data arrays can efficiently utilize the secondary memory <NUM> during execution of the workload <NUM>, the example memory manager <NUM>, the example data element identifier <NUM>, the example data element performance calculator <NUM>, and the example code modifier <NUM> analyze secondary memory consumption (block <NUM>). As described in further detail below, one or more data arrays may be allocated to use higher-performing secondary memory <NUM> if a corresponding performance improvement is expected. In the event that a performance improvement is expected, the example code modifier <NUM> modifies code (e.g., source code, one or more binaries, etc.) associated with one or more data arrays so that the higher-performing secondary memory <NUM> is utilized during execution of the workload <NUM> (block <NUM>). The example linker interface <NUM> invokes a compiler/linker to compile and/or link the modified code to generate a new binary that is improved (e.g., optimized) to utilize the higher-performing secondary memory <NUM> during all or part of the workload <NUM> execution (block <NUM>). In some examples, a compiler is not needed and/or otherwise bypassed when one or more binaries are being modified without concern for corresponding source code. In other examples, profile information may be analyzed and direct the example linker interface <NUM><NUM>, a binary modifier and/or a runtime loader to regenerate one or more binaries.

Turning to <FIG>, additional detail associated with analyzing data access instances (block <NUM>) is shown. In the illustrated example of <FIG>, the example data element performance calculator <NUM> generates a table with data elements (data arrays) that have performed at least one data access attempt to platform <NUM><NUM> memory, such as the example primary memory <NUM> (block <NUM>). For instance, the example table <NUM> of <FIG> includes a data element column <NUM> containing a list of one or more data arrays that have made one or more attempts to access platform <NUM> memory. The example data element performance calculator <NUM> also counts a number of access attempts associated with each data element (block <NUM>), as shown in the example access count column <NUM> of <FIG>. In the event one or more of the data elements in the example data element column <NUM> include a data array that caused the processor <NUM> to wait (e.g., a spin of wasted processor cycles), the example data element performance calculator <NUM> counts a corresponding number of instances of that occurrence (block <NUM>). Additionally, a degree of severity of such processor wait instances is determined by the example data element performance calculator <NUM> by counting a corresponding number of processor cycles that occur during such wait instances (block <NUM>).

To determine temporal portions of the workload <NUM> execution in which one or more data arrays access memory, the example data element performance calculator <NUM> generates a data array profile table <NUM> (block <NUM>), as shown in <FIG>. As described above, the data element performance calculator <NUM> generates a profile associated with each data array to show which relative portion of the workload <NUM> execution is associated with memory access activity. At least one benefit of determining relative temporal locations within the workload <NUM><NUM> where a data array accesses memory, is that the higher-performing secondary memory <NUM> can be judiciously shared between one or more data arrays during execution of the workload <NUM><NUM>. For example, if two data arrays of the workload <NUM> cannot both be utilized simultaneously due to memory size limitations of the secondary memory <NUM>, a first data array may use the secondary memory <NUM> for a portion of the workload <NUM><NUM> execution, and then relinquish the secondary memory <NUM> so that a second data array can utilize the secondary memory <NUM> for the remaining portion of the workload <NUM> execution. The example data element performance calculator <NUM> may also categorize the one or more data elements based on one or more thresholds and/or assign a rank order to determine which data elements should be allocated to the higher-performing secondary memory <NUM> (block <NUM>). In other examples, developing a cost model of performance may indicate that utilization of the secondary memory <NUM> may not result in an appreciated benefit to overall platform performance.

Turning to <FIG>, additional detail associated with analyzing the secondary memory <NUM> consumption (block <NUM>) is shown. In the illustrated example of <FIG>, the example data element identifier <NUM> selects one of the data elements (data arrays) of interest from the table <NUM> of <FIG> and/or the data array profile table <NUM> of <FIG>. In some examples, the data element is selected based on a corresponding rank order, as described above. For instance, the data element associated with a highest processor count wait value may be selected as the best candidate data element for improving (e.g., optimizing) platform <NUM> performance. Higher-performing secondary memory, such as the example secondary memory <NUM>, may be substantially smaller and/or more expensive than primary memory <NUM>. To determine the size of secondary memory <NUM> associated with the platform <NUM>, the example memory manager <NUM> determines a corresponding size of the secondary memory <NUM> (block <NUM>), and determines available remaining space thereof (block <NUM>). In other examples, the size of the secondary memory <NUM> is static and may be performed once rather than within a loop, such as after a workload is obtained (block <NUM>).

If the example data element performance calculator <NUM> determines that the data array of interest exhibits a relatively high occurrence of access attempts to memory throughout the execution of the example workload <NUM> (block <NUM>), then the example memory manager <NUM> determines whether the secondary memory <NUM> has sufficient space to accommodate the data array of interest (block <NUM>). If not, then the example data element identifier <NUM> determines whether additional candidate data arrays are available for consideration (block <NUM>). For example, the data element identifier <NUM> may select the next-highest ranked data array in the table <NUM> of <FIG>. On the other hand, in the event that there is sufficient room in the secondary memory <NUM> for the candidate data array of interest (block <NUM>), then the example code modifier <NUM> flags the data array for modification (block <NUM>) so that, after all candidate data arrays have been considered, the code (e.g., one or more binaries, source code, etc.) associated with the flagged data arrays may be modified (see block <NUM> of <FIG>).

In the event that the data element performance calculator <NUM> determines that the data array of interest attempts to access memory for a portion of time (e.g., a threshold portion) during workload <NUM> execution (block <NUM>), then the example memory manager determines whether such access attempts exceed a threshold demand (block <NUM>). As described above, the threshold demand may be indicative of a number of memory access instances during a period of time during workload <NUM> execution, a relative number of memory access instances when compared to all data arrays and/or based on a number (or relative number) of processor cycles that occur during processor wait periods (spin) due to memory latency and/or bandwidth limitations. During the portion of workload <NUM> execution time at which the data element (data array) of interest exceeds one or more threshold values that are indicative of memory access demands and/or indicative of causing processor cycle delay, the example code modifier <NUM> flags the data element of interest to use the secondary memory <NUM> for that portion of the workload <NUM> execution (block <NUM>). If additional data elements remain in the example table <NUM> of <FIG> and/or the data array profile table <NUM> of <FIG> (block <NUM>), then control returns to block <NUM>.

<FIG> is a block diagram of an example computer <NUM> capable of executing the instructions of <FIG> to implement the workload manager <NUM> of <FIG>. The computer <NUM> can be, for example, a server, a personal computer, a mobile phone (e.g., a cell phone), a personal digital assistant (PDA), an Internet appliance, a gaming console, a set top box, or any other type of computing device.

The computer <NUM> of the instant example includes a processor <NUM>. For example, the processor <NUM> can be implemented by one or more microprocessors or controllers from any desired family or manufacturer.

The processor <NUM> is in communication with a main memory including a volatile memory <NUM> and a non-volatile memory <NUM> via a bus <NUM>.

The computer <NUM> also includes an interface circuit <NUM>.

One or more input devices <NUM> are connected to the interface circuit <NUM>. The input device(s) <NUM> permit a user to enter data and commands into the processor <NUM>. The input device(s) can be implemented by, for example, a keyboard, a mouse, a touchscreen, a track-pad, a trackball, isopoint and/or a voice recognition system.

One or more output devices <NUM> are also connected to the interface circuit <NUM>. The output devices <NUM> can be implemented, for example, by display devices (e.g., a liquid crystal display, a cathode ray tube display (CRT), a printer and/or speakers). The interface circuit <NUM>, thus, typically includes a graphics driver card. The interface circuit <NUM> also includes a communication device (e.g., communication device <NUM>) such as a modem or network interface card to facilitate exchange of data with external computers via a network <NUM> (e.g., an Ethernet connection, a digital subscriber line (DSL), a telephone line, coaxial cable, a cellular telephone system, etc.).

The computer <NUM> also includes one or more mass storage devices <NUM> for storing software and data. Examples of such mass storage devices <NUM> include floppy disk drives, hard drive disks, compact disk drives and digital versatile disk (DVD) drives.

The coded instructions <NUM> of <FIG> may be stored in the mass storage device <NUM>, in the volatile memory <NUM>, in the non-volatile memory <NUM>, and/or on a removable storage medium such as a CD or DVD.

From the foregoing, it will be appreciated that the above disclosed methods, apparatus and articles of manufacture facilitate memory management by identifying candidate data elements, which may include data arrays, stack, heap, etc., that utilize memory resources responsible for platform delay. By rewriting code (e.g., source code, one or more binaries, etc.) in a manner that allocates the candidate data elements to use a higher-performing memory type, the overall operation of the platform may be improved (e.g., optimized) by reducing or even eliminating wasted processor cycles caused by data elements waiting on access to relatively slower memory.

Methods, systems, apparatus and articles of manufacture are disclosed to manage workload memory allocation. Some disclosed example methods include identifying a primary memory and a secondary memory associated with a platform, the secondary memory having first performance metrics different from second performance metrics of the primary memory, identifying access metrics associated with a plurality of data elements invoked by a workload during execution on the platform, prioritizing a list of the plurality of data elements based on the access metrics associated with corresponding ones of the plurality of data elements, and reallocating a first one of the plurality of data elements from the primary memory to the secondary memory based on the priority of the first one of the plurality of memory elements. Additionally, the example methods include the secondary memory having a lower latency than the primary memory, or the secondary memory having a higher bandwidth than the primary memory. In some examples, the access metrics include a number of access attempts by corresponding ones of the plurality of data elements to the primary memory, include detecting whether at least one of the number of access attempts caused a wait event, include counting a number of processor cycles associated with the wait event, and where prioritizing the list of the plurality of data elements includes comparing the number of processor cycles associated with each of the plurality of data elements. Some examples include prioritizing the list of the plurality of data elements by comparing the number of wait events associated with the plurality of data elements, and in other examples identifying the access metrics further includes measuring a number of access attempts per unit of time associated with the plurality of data elements.

Examples disclosed herein also include selecting one of the plurality of data elements to reallocate from the primary memory to the secondary memory when the number of access attempts per unit of time exceeds a threshold value, and further include reallocating a first one of the plurality of data elements from the primary memory to the secondary memory when the number of access attempts per unit of time exceeds a threshold, and reallocating the first one of the plurality of data elements from the secondary memory to the primary memory when the number of access attempts per unit of time is lower than the threshold. Still further examples include the first one of the plurality of data elements utilizing the secondary memory for a first portion of the execution of the workload, and utilizing the primary memory for a second portion of the execution of the workload. Some examples include the first one of the plurality of data elements utilizing the secondary memory while a second one of the plurality of data elements utilizes the primary memory, and other examples include alternating the utilization of the first one of the plurality of data elements from the secondary memory to the primary memory with the utilization of the second one of the plurality of data elements from the primary memory to the secondary memory. The invention includes reallocating the first one of the plurality of data elements from the primary memory to the secondary memory when the secondary memory has space for the first one of the plurality of data elements.

Example apparatus to manage workload memory for data element utilization include a workload manager to identify a primary memory and a secondary memory associated with a platform, the secondary memory having first performance metrics different from second performance metrics of the primary memory, a workload controller to identify access metrics associated with a plurality of data elements invoked by a workload during execution on the platform, a data element performance calculator to prioritize a list of the plurality of data elements based on the access metrics associated with corresponding ones of the plurality of data elements, and a memory manager to reallocate a first one of the plurality of data elements from the primary memory to the secondary memory based on the priority of the first one of the plurality of memory elements. Additional example apparatus include the memory manager selecting the secondary memory based on a lower latency parameter than the primary memory, and in which the memory manager selects the secondary memory based on a higher bandwidth than the primary memory, and/or in which the data element performance calculator is to determine whether an access attempt to the primary memory causes a wait event. Other example apparatus include a code modifier to reallocate data element usage from the primary memory to the secondary memory when a number of access attempts per unit of time exceeds a threshold value, in which the code modifier modifies at least one of source code or a binary associated with the workload.

Claim 1:
A computer-implemented method comprising:
identifying access metrics associated with each of a plurality of data elements invoked by a workload (<NUM>) during execution on a platform (<NUM>) having a first memory (<NUM>) and a second memory (<NUM>), the second memory having a lower latency, coherency and/or higher bandwidth capability than the first memory, wherein the workload is associated with one or more programs of executable code;
wherein identifying the access metrics comprises measuring a number of access attempts per unit of time associated with the plurality of data elements;
the method further comprising:
when the number of access attempts per unit of time is higher than a threshold, reallocating said first one of the plurality of data elements from the first memory to the second memory when the second memory has space for the first one of the plurality of data elements; and
modifying said executable code to generate a new or modified binary utilizing the second memory during all or part of the execution of the workload.