Future resource utilisation prediction

Abstract

A method for predicting future computer resource utilisation comprises obtaining a resource utilisation metric indicating the utilisation of a processing system resource, e.g. memory usage. The utilis

Description

The present technique relates to the field of data processing. More particularly, it relates to resource utilisation monitoring. A data processing system may have resource monitoring circuitry for monitoring utilisation of a processing system resource. For example, the resource monitoring circuitry may provide a resource utilisation metric which gives information on current utilisation of a memory system component such as a cache, interconnect or memory controller. This can provide useful information for controlling resource usage and / or diagnosing problems caused by excessive demand for limited system resource. At least some examples of the present technique provide an apparatus comprising: resource monitoring circuitry configured to obtain a resource utilisation metric indicative of utilisation of processing system resource; and future resource utilisation prediction circuitry configured to predict, based on the resource utilisation metric captured by the resource monitoring circuitry, at least one future resource utilisation metric indicative of predicted future utilisation of the processing system resource; wherein the future resource utilisation prediction circuitry is configured to make said at least one future resource utilisation metric accessible to a system resource management agent. At least some examples of the present technique provide a computer-readable medium storing computer-readable code for fabrication of an apparatus as described above. At least some examples provide a computer program comprising instructions which, when executed by a host data processing apparatus, control the host data processing apparatus to provide an instruction execution environment for execution of target program code, the computer program comprising: resource monitoring program logic configured to obtain a resource utilisation metric indicative of utilisation of processing system resource; and future resource utilisation prediction program logic configured to predict, based on the resource utilisation metric captured by the resource monitoring program logic, at least one future resource utilisation metric indicative of predicted future utilisation of the processing system resource; wherein the future resource utilisation prediction program logic is configured to make said at least one future resource utilisation metric accessible to a system resource management agent. At least some examples of the present technique provide a method comprising: obtaining a resource utilisation metric indicative of utilisation of processing system resource; predicting, based on the resource utilisation metric, at least one future resource utilisation metric indicative of predicted future utilisation of the processing system resource; and making said at least one future resource utilisation metric accessible to a system resource management agent. Further aspects, features and advantages of the present technique will be apparent from the following description of examples, which is to be read in conjunction with the accompanying drawings, in which: Figure 1 schematically illustrates an example of a data processing system comprising resource monitoring circuitry and future resource utilisation prediction circuitry; Figure 2 illustrates an example of a technique for controlling generation of workloadspecific resource utilisation metrics and controlling resource allocation for a particular workload; Figure 3 illustrates an example of future resource utilisation prediction circuitry; Figure 4 illustrates a method; Figure 5 illustrates an example of pre-processing of resource utilisation metric values to generate time series input data for input to a prediction model; Figure 6 illustrates how a trained mixture-of-experts model is able to accurately predict future latency metrics quantifying request latency in a network-on-chip; Figure 7 illustrates, for comparison, results of predicting future request latency metrics using a linear regression model which uses time series input data with an equivalent number of training examples to the number of training examples used to train the mixture-of-experts model used to generate the data shown in Figure 6; Figure 8 illustrates how, with increasing numbers of training examples, the mixture-of-experts and linear regression model converge at equivalent prediction accuracy; and Figure 9 illustrates a simulation example. An apparatus has resource monitoring circuitry configured to obtain a resource utilisation metric indicative of utilisation of processing system resource. Such resource utilisation metrics can be useful to a system resource management agent responsible for controlling resource utilisation by respective workloads. For example, the system resource management agent may make decisions to restrict the amount of processing system resource (e.g. memory bandwidth, cache storage capacity) available to a given workload based on the resource utilisation metrics, to try to reduce risk that a given workload is starved of resource due to being drowned out by requests issued by a “noisy neighbour” workload which is generating a much higher frequency of requests. However, a problem with making resource management decisions based on resource utilisation metrics indicative of current utilisation of processing system resource is that, by the time a system resource management agent receives such metrics and processes them to make decisions on resource management, the system demand may have changed and the previously captured metrics may no longer reflect the current operating conditions. The time lag between capturing a resource utilisation metric and making control decisions or updating resource configuration settings based on the metric may cause inefficient usage of resources, e.g. underutilisation of resource if there has been a drop in system demand between the metric being captured and the metric being used to control resource management, or over-utilisation of resource if system demand has risen since the metric was captured. In the examples discussed below, the apparatus comprises future resource utilisation prediction circuitry configured to predict, based on the resource utilisation metric captured by the resource monitoring circuitry, at least one future resource utilisation metric indicative of predicted future utilisation of the processing system resource. The future resource utilisation prediction circuitry is configured to make the at least one future resource utilisation metric accessible to a system resource management agent (e.g. software or hardware responsible for controlling configuration of processing system resources). By exposing to a system resource management agent a prediction of future resource utilisation, not just a metric expressing current resource utilisation, this provides a better indication of the resource utilisation conditions likely to be experienced at the time when the system resource management agent acts upon the future resource utilisation metric (e.g. by selecting updated resource configuration settings, such as limits on maximum resource usage by certain workloads). Hence, a platform which includes the future resource utilisation prediction circuitry is able to provide more useful information on resource utilisation status than can be provided in a system only comprising the resource monitoring circuitry which monitors current resource utilisation, as the provision of at least one future resource utilisation metric enables the problem of time lag between measurement and control to be overcome. In general, the resource utilisation metric (and hence also the predicted future resource utilisation metric) may relate to any processing system resource, including resources at a central processing unit or other processor of a processing system. However, in some examples, the resource utilisation metric comprises a memory system utilisation metric indicative of utilisation of memory system resource. It can be particularly useful to provide a prediction of future utilisation of memory system resource, because often the memory system of a processing system may be heavily contended for access from multiple requesters operating under control of different software processing workloads, so it may be harder for the developer of any particular one of those software workloads to provide software hints as to expected future memory system utilisation, as the peaks and troughs of overall utilisation of memory system components (such as caches, memory system buses or interconnects, request buffers, memory controllers, etc.) may depend on behaviour of multiple different software workloads. However, a prediction model may be provided which monitors trends in current resource utilisation and uses them to predict future resource utilisation. The future resource utilisation metric can provide useful inputs to resource control algorithms which control applying restrictions on use of memory system resource by a particular workload to preserve quality of service for other workloads. In some examples, the resource utilisation metric is indicative of at least one of: latency of requests serviced using the processing system resource; throughput of requests serviced using the processing system resource; and / or spare resource capacity of the processing system resource. Such metrics can be useful for making resource management decisions. By predicting a future metric expressing predicted latency, request throughput, and / or spare resource capacity and exposing such a future metric to a system resource management agent, the system resource management agent can make better control decisions which may better account for the time lag between resource utilisation measurement and the control action being implemented. Although this technique could be applied to monitoring of utilisation of any memory system component, it can be particularly useful where the resource utilisation metric is indicative of utilisation of a memory system interconnect configured to route memory system requests between one or more requesters and one or more completers. A memory system interconnect (e.g. point-to-point interconnect, mesh network or network on chip) may be particularly vulnerable to peaks and troughs of resource utilisation, which may be relatively hard to anticipate based on software-provided hints alone, if the interconnect is heavily contended between different requesters. However, the inventors have recognised that prediction models are available which can process past or current interconnect utilisation measurements to predict interconnect utilisation metrics for future times, so that better information for resource management decisions can be provided. The future resource utilisation prediction circuitry may operate at runtime to provide a runtime prediction of future utilisation of the processing system resource. Hence, the system resource management agent may be able to react dynamically to make resource management decisions at runtime, to improve resource utilisation as software workloads are being executed on the processing system. The future resource utilisation prediction circuitry may process time series input data dependent on a plurality of instances of the resource utilisation metric captured at different past times using a prediction model, to predict the at least one future resource utilisation metric for at least one future time. Hence, based on a given number of input data samples characterizing past resource utilisation, the prediction model is able to predict one or more instances of the future resource utilisation metric for a given future window of time. This future prediction can then be exposed to the system resource management agent for use in control algorithms. In some examples, each data item of the time series input data comprises a value obtained by applying an aggregate function to a plurality of instances of the resource utilisation metric captured within a respective past time window. For example, the aggregate function could be an average (e.g. mean or median), maximum or minimum of the plurality of instances of the resource utilisation metric captured in the corresponding time window. By aggregating multiple instances of the resource utilisation metric to produce an aggregate value summarising those instances, and forming the time series input data from a series of such aggregate values, this can reduce sensitivity of the time series input data to noise, and reduce the computational (e.g. energy and latency) cost of processing the time series input data by reducing the overall number of input data points processed by the prediction model. In some examples, the future resource utilisation prediction circuitry may be configurable based on at least one configuration input controllable by a control agent (e.g. software executing on a general purpose processor, a system control processor and / or the system resource management agent). For example, the at least one configuration input may specify parameters such as: - which particular resource utilisation metric provided by the resource monitoring circuitry is used to generate the future resource utilisation predictions by the future resource utilisation prediction circuitry; - how many samples of the resource utilisation metric captured at different past times are to be used as the time series input data for the prediction model; how many instances of the future resource utilisation metric are to be predicted for future times. the duration of each aggregation time window over which instances of the resource utilisation metric are aggregated as discussed above. A wide variety of types of prediction model could be used as the prediction model for predicting future resource utilisation. In some examples, the prediction model comprises a machine learning model. The machine learning model can be trained based on training examples (comprising sets of time series input data comprising past resource utilisation metric values and corresponding future resource utilisation metric values) derived either from real resource utilisation metrics on a hardware system or from simulated resource utilisation metrics on a simulated system, to derive model parameters which express the relationship between a given time series input and the corresponding future resource utilisation metric(s). A wide variety of machine learning model types are possible. In some examples, the prediction model comprises a regression model. For example, a linear regression model may be used. During a training phase model parameters may be derived from training data by linear regression, and during an inference phase the model parameters may be applied to the time series input data derived from the metrics measured by the resource monitoring circuitry, to obtain the predicted future resource utilisation metric(s). It has been found by testing on simulated metric data that a linear regression model can give good enough performance, at least when the number of training examples used for training is high enough. In some examples, the prediction model comprises a transformer model. Transformer models are particularly good at handling predictions of future items of a sequential series of data items, and form the basis of many Large Language Models (LLMs) which are commonly used for text generation and other generative artificial intelligence use cases. A series of resource utilisation metric values corresponding to past / future times can be seen as such a sequential series of data items, and so use of a transformer model can be particularly effective for accurate prediction of future resource utilisation from past resource utilisation metrics. More particularly, the prediction model may comprise a decoder-only transformer model, which is a class of transformer models which is particularly focused on generation of sequential data and which can be easier to train than more complex encoder-decoder transformer models. In some examples, the prediction model comprises a mixture-of-experts model. The mixture-of-experts model may comprise a plurality of expert models (each defined by a corresponding set of expert model parameters), and a router model (defined by a corresponding set of router model parameters) configured to select, based on the time series input data, which subset of the expert models is to be used for processing the time series input data to generate the at least one future resource utilisation metric. If multiple expert models are selected by the router model, the outputs of the selected expert models can be combined to form the at least one future resource utilisation metric. During a training phase, the expert models can be trained to handle a different subset of the input parameter space of the time series input data, and the router model can be trained to select for particular time series input data which of the experts to select for processing that input data. Each of the expert models may, for example, comprise a transformer model (e.g. decoder-only transformer model) as discussed above. A mixture-of-experts model can be particularly useful for implementing the prediction model applied by the future resource utilisation prediction circuitry, because the mixture-of-experts model can provide, for a given level of prediction accuracy, a more efficient model in terms of power consumption, compared to a single model which handles the entire input data space with a common set of model parameters. Compared to a single unified model, the mixture-of-experts approach allows for an increase in the overall model’s parameter count (hence improving accuracy), while effectively controlling computational costs and latency because only a reduced subset of the expert models are invoked for any particular prediction. Testing based on simulated series of resource utilisation metrics has shown that use of a mixture-of-experts model can be extremely effective in accurately predicting future trends in resource utilisation, even when the training data set includes relatively few training examples, which can be helpful in reducing the computational cost of implementing model training (to the point where it can become feasible to run the training online at runtime following a change in workload behaviour to adapt the model to that particular workload). In some examples, the future resource utilisation prediction circuitry comprises model training circuitry to adapt parameters of the prediction model based on a training data set comprising training data items each providing a corresponding set of past resource utilisation metric data and future resource utilisation metric data captured by the resource monitoring circuitry. Hence, in implementations which support model training circuitry, a training phase for the prediction model can be triggered from time to time, to allow the model to be trained to learn new model parameters based on training data sets specific to a particular set of workloads to be processed on the processing system. This can allow the predictions to be better tailored to the particular workloads being processed. However, other examples may not support such model training circuitry, and may provide a pre-trained prediction model which is defined by model parameters derived during a training phase performed offline, for example based on generic training data obtained by resource 7 utilisation monitoring in a test system or based on simulated training data obtained by computer simulation of a processing system. Therefore, it is not essential to provide circuitry for adapting the model parameters by repeating the training phase. Some examples may perform the training phase of the machine learning model only offline (e.g. in a design phase when the processing system is being designed). The future resource utilisation prediction circuitry can be implemented in different ways within the processing system. In some examples, the future resource utilisation prediction circuitry is configured to implement the prediction model using dedicated hardware. For example, the future resource utilisation prediction circuitry may comprise hardwired sets of logic gates which implement one or more mapping functions between the time series input data and the future resource utilisation predictions according to the prediction model. In other examples, the prediction model could be implemented using software executing on a generic processing unit. Hence, the future resource utilisation prediction circuitry may comprise processing circuitry configured to execute software implementing the prediction model. For example, a microcontroller or other processor may be built into the processing system, dedicated to executing software defining the prediction model. Alternatively, the prediction model software may run on a general purpose processor also used for other processing tasks. In some examples, at least one control setting may be provided in which the resource monitoring circuitry obtains a workload-specific resource utilisation metric indicative of utilisation of the processing system resource by a specific processing workload, and the future resource utilisation prediction circuitry obtains the at least one future resource utilisation metric indicative of predicted future utilisation of the processing system resource by the specific processing workload. This can be useful for more fine-grained control over processing system resources based on expected resource requirements of particular processing workloads. By providing prediction of the future resource utilisation requirements of a particular workload, this can be helpful for a system resource management agent to make control decisions regarding the way in which that workload can use processing system resource (e.g. in setting limits on resource utilisation by that workload). For example, memory system requests issued to a memory system by a processor may specify workload identifying information (e.g. settable based on software-configurable control registers of the processor which can be updated by software operating with at least a given threshold level of privilege), which identifies which particular software workload caused that memory system request to be issued. The workload identifying information may propagate through the memory system along with the corresponding memory system requests, to allow the resource monitoring circuitry associated with a given memory system component to gather workload-specific resource utilisation metrics based on detecting requests associated with a particular workload identifier. The future resource utilisation metric predictions can be particularly effective in a system comprising resource control circuitry to control allocation of memory system resource to a given processing workload, based on at least one configurable resource control parameter configurable at runtime by the system resource management agent. For example, configurable controls may be provided enabling software or another system resource management agent to control allocation of resource (such as bandwidth on a bus or interconnect or capacity within a cache) assigned to memory system requests initiated by a particular workload. The agent managing such controls may find the future resource utilisation metrics particularly helpful in deciding how to set the at least one configurable resource control parameter, as it can help account for the time lag between metric measurement and the workload-specific resource allocation control setting being implemented. Hence, in some examples the system resource management agent may determine a control setting for the at least one configurable resource control parameter based on the at least one future resource utilisation metric. The future resource utilisation prediction circuitry may make the at least one future resource utilisation metric accessible to the system resource management agent by writing the at least one future resource utilisation metric to a software-accessible storage location. For example, the software-accessible storage location could be a register (e.g. memory-mapped register) or could be a memory location (e.g. a memory location corresponding to an address determined relative to a base address programmed in a register associated with the future resource utilisation prediction circuitry). The system resource management agent may be implemented in different ways. In some examples, the system resource management agent comprises software executed by processing circuitry. In that case, the system resource management agent itself may not be a hardware feature of the apparatus described above. The resource management software may not yet be installed on the apparatus at the time the apparatus is manufactured or sold, so the actions taken by the resource management software are not an essential part of the apparatus. Hence, from a platform point of view, in some examples the future resource utilisation prediction circuitry may have an interface (e.g. a set of memory-mapped registers accessible by software) to expose the future resource utilisation metric predictions to the system resource management agent, but the apparatus itself may not actually comprise the system resource management agent (the software may not yet be installed). In other examples, the system resource management agent comprises memory system resource control circuitry implemented in hardware. For example, a dedicated memory system resource management processor may be provided in hardware to process resource utilisation metrics and future resource utilisation metrics and make control decisions for setting resource control parameters. Specific examples are now described with reference to the drawings. Figure 1 illustrates an example of a processing system 2 comprising one or more memory access initiators. In this example the memory access initiators include one or more processing elements capable of instruction execution. The processing elements include one or more central processing units (CPUs) 4 and can also include other types of processing element such as a graphics processing unit (GPU) 6. The memory access initiators can also include other nonprocessing-element memory access initiators such as an input / output (I / O) device 10. While Figure 1 for sake of example shows two CPUs 4, one GPU 6, and one I / O device 10, it will be appreciated that the system 2 could include different numbers of initiators of a given type, could include additional types of memory access initiators not shown in Figure 1 (e.g. a hardware accelerator) and may not necessarily include all of the types of memory access initiators 4, 6, 10 shown in Figure 1. The memory access initiators 4, 6, 10 communicate with each other and with memory storage 20 via a system interconnect 14. Some of the access initiators (e.g. CPUs 4) may have private caches 12 for caching data or instructions obtained from memory 20. The system 2 may also comprise a system cache 16 which is shared between multiple initiators 4, 6, 10. It will be appreciated that Figure 1 is merely a simplified representation of some components of a possible processing system, and the system could include other elements not illustrated for conciseness. The system 2 has at least one instance of resource monitoring circuitry 30 for generating one or more resource utilisation metrics indicating current utilisation of processing system resource. For example, the processing system resource may be a memory system resource, such as a cache 12, 16, the interconnect 14 or a given sub-component of the interconnect 14 (such as a queue or buffer structure or a network-on-chip router), or other resources such as memory controller queues in a memory controller for controlling a specific memory storage unit 20 (the memory controller is not shown in Figure 1). The resource utilisation metric could, for example, be a measure of request latency experienced by requests being processed by a given part of the memory system, a measure of request throughput (the number of requests processed in a given time), and / or a measure of the amount of spare resource capacity (e.g. cache capacity, bus / interconnect bandwidth or buffer / queue slots). It will be appreciated that there can be a wide variety of metrics that could be gathered by the resource monitoring circuitry 30. While Figure 1 shows an example where one instance of the resource monitoring circuitry is provided at a CPU 4 (e.g. for monitoring utilisation of the CPU’s private cache 12) and another instance of the resource monitoring circuitry 30 is provided at the memory system interconnect 14 (e.g. for monitoring usage of bandwidth on the interconnect 14 or an interconnect sub-component), it is not essential for both of these instances of resource monitoring circuitry 30 to be provided, and some examples could only provide one of these instances. Also, it would be possible to provide resource monitoring circuitry 30 associated with other processing system resources (e.g. associated with a memory management unit (MMU) responsible for address translation, for monitoring metrics relating to the current utilisation of the memory management unit). The system 2 may comprise (at least when in use at runtime), a system resource management agent 34 which is responsible for managing utilisation of system resources. For example, the system resource management agent 34 could control resource control settings that set limits on the amount of memory system resource (e.g. cache capacity, bus / interconnect bandwidth, MMU bandwidth, etc.) that can be consumed by requests from a given hardware requester 4, 6, 10 or a given software workload executing on the CPUs 4. The system resource management agent 34 could, in some examples, be implemented as software running on a CPU 4, in which case the hardware system 2 does not include a permanent component corresponding to the system resource management agent 34 (at the time the system 2 is manufactured or sold, the software of the system resource management agent 34 may not have been installed yet). Alternatively, the system resource management agent 34 could be implemented as a hardware processing unit which controls resource utilisation configuration settings (e.g. as a processing unit coupled to the memory system interconnect 14 as shown in one of the alternative examples of system resource management agent 34 shown in Figure 1). Either way, the resource utilisation metrics captured by the resource monitoring circuitry 30 may be exposed to the system resource management agent 34 (e.g. by writing the metrics to locations in memory 20 or to registers accessible to the system resource management agent 34), and the system resource management agent 34 may use those metrics to decide how to set the resource utilisation configuration settings for particular memory system resources such as a cache 12, 16, interconnect 14, request buffer, memory controller, etc. As shown in Figure 1, the system 2 also includes at least one instance of future resource utilisation prediction circuitry 32, which predicts, based on time series input data formed based on respective values of a resource utilisation metric captured by the resource monitoring circuitry 30 at various past times, at least one future value of the resource utilisation metric corresponding to a future time, and exposes such predicted future values of the resource utilisation metric to the system resource management agent 34. The predicted future resource utilisation metric values can be exposed to the system resource management agent 34 in various ways, such as by writing those values to a memory location or register (e.g. memory-mapped register) which is accessible to the system resource management agent 34, or in the case where the system resource management agent 34 is implemented in hardware, by transmitting the predicted future values to the system resource management agent 34 via a dedicated signal path. While Figure 1 shows both instances of the resource monitoring circuitry 30 having associated future resource utilisation prediction circuitry 32, this is not essential and there can be some instances of the resource monitoring circuitry 30 which are not associated with any corresponding future resource utilisation prediction circuitry 32 and so do not support generation of predicted future values of that resource utilisation metric. At least one instance of the resource monitoring circuitry 30 is associated with a corresponding instance of future resource utilisation prediction circuitry 32. It may also be possible that some instances of future resource utilisation prediction circuitry 32 may be shared between multiple instances of resource monitoring circuitry 30, with a configuration input (set by software executing on the CPU or by the system resource management agent 34) controlling which particular metric from the respective instances of resource monitoring circuitry 30 is subject to the future resource utilisation prediction. Figure 2 illustrates in more detail an example of maintaining workload-specific resource utilisation metrics and controlling resource usage for memory system requests issued for a given software workload. A processing element, such as a CPU 4, may have a processing pipeline 24 for processing instructions, and registers 26 which may include general purpose registers for storing instruction operands and results of processing instructions and system registers for storing control information for controlling the operation of the processing element 4. The processing element 4 also includes a load / store unit 29 which issues memory access requests to the memory system in response to load / store instructions executed by the processing pipeline 24 and in response to instruction fetch requests generated by the processing pipeline 24 to fetch instructions to be executed. The processing element 4 supports an instruction set architecture which provides software with the ability to define, for a given software workload, one or more workload identifiers (also referred to as partition identifiers and / or performance monitoring group identifiers) which distinguish one software workload from another. Such workload identifiers can be specified in memory system requests sent out to the memory system, and propagate through the memory system along with those requests, so that memory system components can identify which software workload a given request relates to. In particular, the registers 26 of the processing element 4 include a set of workload identifier registers 28 used to set one or more workload identifiers which are specified by a memory system request sent to the cache 12 of the processing element 4 or other parts of the memory system. The processing element 4 includes circuitry (e.g. the load / store unit 29) which selects which items of workload identifying information are specified by the memory system request, based on the information stored in the one or more workload identifier registers 18. The workload identifying information specified by the memory system request may include one or more identifiers which act as a label to distinguish memory system requests issued on behalf of different execution environments (e.g. different software execution environments executed by the processing element 4). The workload identifying information does not influence which addresses in memory are allowed to be accessed by a particular execution environment, but is used for resource allocation control for regulating the level of performance seen for memory accesses issued by a particular execution environment and / or for control of resource utilisation monitoring so that separate resource utilisation metrics can be gathered for different workloads (execution environments). As shown in Figure 2, a given memory system component (e.g. system cache 16, interconnect 14, memory controller of memory 20, or private cache 12) could include resource allocation control circuitry 38 which uses the workload identifying information for selecting resource allocation control settings, e.g. which limit the amount of memory system bandwidth which a particular execution environment is allowed to use, or limit a maximum fraction of cache capacity that a given execution environment is allowed to allocate for its own information. The resource allocation control circuitry 38 may have access to a number of sets of resource allocation setting information 39 (each set corresponding to a given value of the workload identifying information), which specifies how to control resource allocations for requests specifying that value of the workload identifying information. For example, the resource allocation settings 39 may be defined in a memory-based table structure stored in memory 20 which is accessed at an address determined based on a base address defined in a register of the memory system component 16, 14, 20, 12. The base address register may be memory-mapped so that the base address can be set by software executing on a CPU 4 by executing a store instruction specifying an address mapped to the base address register. Alternatively, other configuration interface mechanisms may be provided as a configuration interface 37 of the memory system component 16, 14, 20, 12 to allow software to control the resource allocation settings for handling requests with a given value of the workload identifying information. In general, such resource allocation controls can be useful to prevent a “noisy” execution environment (which generates frequent cache requests) monopolizing a significant fraction of the available memory system resource (which may otherwise harm performance for other execution environments with less frequent requests which might not be able to gain sufficient usage of memory system resource if the amount of resource used by the “noisy” execution environment was not limited). Also, as shown in Figure 2, at least one instance of the resource monitoring circuitry 30 can have a similar configuration interface 37 for configuring the resource monitoring circuitry 30 to maintain resource utilisation metrics for one or more distinct workloads as identified by respective values of the workload identifying information. When a memory system request specifying a given value of the workload identifying information is detected, the resource monitoring circuitry 30 checks whether that value of the workload identifying information corresponds to a workload for which a workload-specific resource utilisation metric is to be maintained, and if so updates a corresponding one of the workload-specific resource utilisation metrics 35. The gathered metrics 35 are made available for access by the system resource management agent 34 (e.g. software on a CPU or a hardware processor responsible for resource allocation control). Hence, the workload identifier control registers 28 provide a mechanism by which software executing on the CPU 4 may control labelling of memory access requests to assign workload identifiers to memory access requests, which can be used to control resource allocation and / or gathering of workload-specific resource utilisation metrics at a memory system component within the memory system. In some examples, the workload identifying information assigned to a given memory access request may include more than one identifier, e.g.: a partition identifier (PARTI D) which is used to control which set of resource allocation settings are applied by resource allocation control circuitry 38 of a memory system component 16, 14, 20, 12; and a performance monitoring group identifier (PMG) which is used by resource monitoring circuitry 30 to select which of several workload-specific resource utilisation metrics are to be updated based on the memory access request. In some examples, the PARTID and PMG may be considered independent identifiers, with the resource allocation control circuitry 38 selecting between resource allocation control settings based on the PARTID (independent of PMG) and the resource monitoring circuitry 30 selecting which resource utilisation metric to update based on the PMG (independent of PARTID). Alternatively, one of the PARTID and PMG may be regarded as a sub-identifier which distinguishes between different sub-classes of workloads corresponding to a given value of the other identifier. For example, while resource allocation control may be based on PARTID only (independent of PMG), resource monitor selection may be based on the combination of PARTID and PMG (so that workloads having the same PARTID but different PMGs might have different resource utilisation metrics maintained specific to each of those workloads even though the workloads share the same resource allocation settings controlled based on PARTID). The opposite approach is also possible, with resource utilisation monitor selection based on PMG only and resource allocation control based on the combination of PARTID and PMG. Regardless of the particular approach taken, providing multiple identifiers can give more flexibility in providing different granularity of control over resource allocation control compared to resource utilisation monitoring. However, it will be appreciated that providing multiple identifiers is not essential, and other approaches may provide a single identifier used to control both selection of resource allocation settings applied by resource allocation control circuitry 38 (e.g. caps on maximum cache allocation or maximum bandwidth consumption) and for selection of which resource utilisation metric to update. Another item of workload identifying information that can be specified for a given memory access request may be a workload identifier space indicator. For example the processing element 4 may support execution of software in one of a number of security states, and software in different security states might specify the same value of PARTID or PMG in the workload identifier registers 28, but to maintain secure isolation between the software operating in different security states, it may be desirable to prevent software in one security state influencing resource allocation control or resource utilisation monitoring associated with memory system requests issued from another security state. Therefore, as well as the PARTID / PMG identifiers, the workload identifying information specified by a memory access request could also include an workload identifier space indicator (e.g. an identifier of the security state from which the memory access request is issued), which distinguishes between multiple workload identifier spaces which are assigned separate resource allocation settings or separate workload-specific utilisation metrics even for requests specifying the same values of PARTI D / PMG. The processing element 4 could select the workload identifier space indicator for a given memory access request based on a current security state of the processing element 4 at the time the memory access request is issued. Hence, it will be appreciated that there can be a wide variety of ways in which workload identifying information can be specified. In general, any information can be assigned to memory access requests which enables the software workload that caused that request to be issued to be distinguished by a memory system component or instance of resource monitoring circuitry 30. The architectural mechanism for setting the workload identifiers used for particular software workloads may be based on providing a set of one or more workload identifier control registers 28. In some examples, there may be a single workload identifier control register 28 to which one or more workload identifiers (e.g. PARTID and / or PMG) can be written by software. In such implementations, memory access requests issued by the processing circuitry 4 specify the workload identifier(s) currently specified in the register 28. When switching between different portions of software requiring their memory access requests to be distinguished from each other for performance resource control or resource utilisation monitoring purposes (e.g. on a context switch), software updates the workload identifier control register 28 to specify the workload identifier(s) for the new software to be executed after the switch, and then subsequent memory access requests will specify the new workload identifier. Other examples could implement multiple workload identifier control registers 28 specifying workload identifiers associated with different operating states (e.g. privilege levels or exception levels associated with the processing element 4), and the current operating state of the processing element 4 at the time a memory system request is issued may be used to select which workload identifier control register is selected, and hence which workload identifier(s) is / are specified in the memory system request. For example, this can be useful to avoid software needing to rewrite workload identifier control registers 28 each time there is a supervisor call or exception taken to a more privileged operating state or an exception return back to a less privileged operating state, which may be relatively frequent events. Some implementations may provide an architectural mechanism for enabling different workload identifiers for to be specified for different classes of memory access request issued in the same software execution environment (with the same setting for the workload identifier control registers 28). For example, there may be fields within the workload identifier control registers 28 for specifying different workload identifiers for data access requests issued in response to load / store instructions executed by the processing pipeline 24, instruction fetch requests issued to fetch instructions for processing by the pipeline 24, and / or page table walk requests issued by the processing circuitry 4 to request access to page table information used to translate addresses of memory access requests. Also, in some cases the workload identifier(s) specified in the memory access request sent to the memory system may not be exactly the same as the workload identifier value(s) stored in the relevant workload identifier control register 28. Some implementations may support a workload identifier virtualisation scheme where a virtual workload identifier written by software to the workload identifier control registers 28 is remapped to a physical workload identifier appended to the memory system request, based on workload identifier remapping information which can be defined by software. This can allow a number of different pieces of less privileged software (e.g. operating systems) to coexist on the same hardware platform while independently setting the workload identifiers to be used for different software execution environments managed by the less privileged software, with more privileged software (e.g. a hypervisor) defining the workload identifier remapping information so that conflicting workload identifiers set by different operating systems can be mapped to different workload identifiers as seen by the memory system. Hence, it will be appreciated that there are a wide variety of ways in which the workload identifier of the memory access request could be determined, but in general the processing element 4 includes selection circuitry to select workload identifying information to be specified for a given memory system request, with the particular value of the workload identifying information being selected depending on at least one workload identifier specified in a software-writable architectural register 28 of the processing element 4 (and also possibly depending on a current operating state, e.g. exception level and / or security state, of the processing element 4). While the future resource utilisation prediction technique described in this application is useful even in a system which does not support the tagging of memory system requests with workload identifying information, the future resource utilisation prediction can be particularly effective in a system offering the ability for a system resource management agent 34 to control resource utilisation by requests from a particular software workload by setting the corresponding workload-specific resource allocation settings 39 to be used for requests specifying a given workload identifier. The system resource management agent 34 can use the predictions of future resource utilisation by the future resource utilisation prediction circuitry 32 to determine how to set the workload-specific resource allocation settings 39 for a given workload based on prediction of future utilisation of resources by the future resource utilisation prediction circuitry 32, so that the time lag between resource metric collection and applying resource control settings can be accounted for to reduce the risk that there is under-utilisation or over-utilisation of resource by a particular workload due to the demand for resource changing in the period between collecting the relevant utilisation metric and applying corresponding resource control settings determined based on the metric. Figure 3 illustrates an example of the future resource utilisation prediction circuitry 32 in more detail. The future resource utilisation prediction circuitry 32 receives, from a given instance of resource monitoring circuitry 30, raw values for a given resource utilisation metric captured at a series of time points. Each resource utilisation metric value is indicative of current utilisation of a given memory system resource at the corresponding time point. For example, the resource utilisation metric could be a request latency metric, a throughput metric such as the number of requests handled in a given period of time, or a spare capacity metric indicative of unused cache capacity of bus / interconnect / queue bandwidth in a given period. The future resource utilisation prediction circuitry includes a pre-processing unit 42 to apply pre-processing to the raw metric values received by the resource monitoring circuitry 30 to generate a set of time series input data to be input to a prediction model 44. For example, the pre-processing unit 42 may aggregate groups of raw metric values to generate a set of fewer input values to use as the time series input data. For example, the raw metric values corresponding to time points within a given time window may be processed using an aggregate function (e.g. mean, median, maximum, minimum) to generate an aggregate value. The time series input data may be formed from the aggregate values generated based on the raw metric values captured in a series of time windows. Other examples could omit the pre-processing step 42 and simply input the raw metrics themselves as the time series input data for the prediction model 44. However, applying some pre-processing to reduce the number of variables of the model input can be helpful for reducing computational cost of implementing the prediction model 44 (helpful for reducing power consumption) and for reducing influence of noise on the predictions made by the future resource utilisation prediction circuitry 32. The time series input data is input to the prediction model 44, which implements a set of mapping functions for mapping the values of the time series input data to corresponding values of one or more future resource utilisation metric(s) corresponding to future time points. Those mapping functions are configurable based on a set of model parameters 46 learned in a training phase from training examples (sets of time series input data and corresponding future resource utilisation metric values). During the training phase error minimisation functions can be applied to adapt the model parameters 46 based on the error between predicted future resource utilisation metric(s) calculated from a given set of time series input data fora current set of model parameters 46 and the corresponding actual future resource utilisation metric values which were observed (in real life operation of a system 2 or in simulation) as being the values of the resource utilisation metric which follow at future times after the earlier times at which the resource utilisation metrics used to generate the time series input data were recorded. In some examples, the future resource utilisation prediction circuitry 32 may include model training circuitry 50 to perform the training phase at runtime, to allow the model parameters 46 to be adapted based on specific training data gathered during running of the system 2 when executing a given set of software workloads on the CPUs 4, GPU 6 etc. This can allow the model to be trained more precisely to adapt to the particular behaviour of the workloads being executed. Other examples may not include the model training circuitry 50, and the prediction model 44 may operate according to pre-defined model parameters 46 developed in an offline training phase performed using representative training examples captured either on a real processing system executing benchmark workloads or by computer simulation. On the other hand, in an inference phase of the prediction model 44, the time series input data generated by pre-processing is input to the model, and the previously learnt model parameters 46 are used to map the time series input data to the corresponding prediction of one or more future resource utilisation metric values. In other words, the prediction model 44 synthesises future time points to extend the time series input data into the future. The prediction model 44 itself may be implemented in many different ways. In general a machine learning model is used, enabling the model parameters 46 to be learnt in a training phase based on training examples providing time series input data and future time points for the same time series. Some examples may implement a relatively simple regression model (e.g. linear regression). Other examples, may implement more complex model types. As the prediction model 44 is generating an extension of a set of symbols (the earlier part of the time series input being used as a prompt to the model and the predicted future resource utilisation metric values being an extension of that series of symbols), machine learning models commonly used for synthetic text generation or large language models, such as transformer models, may be particularly effective. In particular, the prediction model may be a decoder-only model. However, one consideration for the model selection may be that, when inbuilt in a data processing system 2, there may be a limited amount of computational resource (power, circuit area, latency) available for the future resource utilisation prediction processing. One particular class of models which can be particularly helpful for achieving a better balance between prediction accuracy and computational overheads can be a mixture-of-experts model, such as Mixtral, which provides a set of trainable models including a number of expert models (each trained to handle a different subset of the input space) and a router model which is trained to select, for a given input, which of the expert models to select for processing the input. This allows greater overall model complexity (and hence higher ceiling for prediction accuracy) while ensuring that computational overhead is kept within limits by not using all model parameters for each prediction. Regardless of the type of prediction model used 44, the model 44 (and any pre-processing 42 or training 50 functions) may be implemented either as dedicated hardware, or as software executing on a general purpose processor (e.g. a small micro-controller coupled to the memory system fabric). The future resource utilisation metrics generated by the prediction model 44 may be written to one or more registers 48 (or to other storage locations such as locations in memory 20), from which they can be read by system resource management agent 34 as inputs to algorithms for controlling resource allocation settings. Figure 4 illustrates a method of generating a future resource utilisation prediction. At step 100, the resource monitoring circuitry 30 obtains a resource utilisation metric indicative of utilisation of processing system resource. At step 102, the future resource utilisation prediction circuitry 32 predicts, based on the resource utilisation metric, at least one future resource utilisation metric indicative of predicted future utilisation of the processing system resource. At step 104, the future resource utilisation prediction circuitry 32 makes the at least one future resource utilisation metric accessible to a system resource management agent 34. The at least one future resource utilisation metric could express the resource utilisation metric for a single instant of future time, or could include metric values for more than one future time, which can give more fine-grained information on future resource utilisation trends predicted to occur. Either way, the future resource utilisation metric value(s) can be a useful input to a resource allocation control algorithm implemented by system resource management agent 34 (e.g. algorithms for setting the workload-specific resource allocation settings 39 described above). Figures 5 to 8 show investigations carried out to demonstrate feasibility of the future resource utilisation prediction technique. As shown below, promising results have been obtained using a Large Language Model (LLM), namely Mixtral, to perform forecasting on a timeseries of resource utilisation metric values, although other model types (e.g. linear regression model) can also be effective in some use cases (e.g. given a large enough set of training examples). In the investigations described below, the particular resource utilisation metric subject to future utilisation prediction was a flit latency metric which expresses average latency of flits (flow digits) conveyed in a network on chip (a particular implementation of a memory system interconnect 14). Slow flit latencies may be indicative of congestion occurring at particular components (e.g. routers) within the network on chip, so it can be useful to forecast future instances of congestion to allow pro-active setting of resource control parameters to reduce the likelihood of such congestion causing stalling of critical memory access requests. Of course, while this particular example applies the prediction technique to a flit latency metric, the same technique could be used for any other type of resource utilisation metric to predict future trends of development of that metric. In the investigations carried out, prompts and test samples were generated by simulation. For each series of raw time series flit latency metric measurements, the obtained timeseries of raw measurements was pre-processed as shown in Figure 5: • an average value was computed over a window of 10 consecutive measurements; such window slides with a stride equal to 10; • each input-target pair was built by considering sequences of 16 values within the newly constructed time series; the first 15 values represent the input sample, and the last one is the target to be predicted. Of course, the size of the aggregation windows (10) and size of the input-target pair (total 16 measurements, with 15 inputs to 1 target) are just one example, and other examples could vary these size parameters. In some cases, the prediction circuitry 32 may be configurable by software to adjust the size of the window over which aggregation is performed, the size of the input sequence and / or the size of the target to be predicted. Hence, the training set of data comprises a number of train / test samples, each comprising a time series input data and a corresponding target value (the target value being the next element of the series of aggregated average values after the 15 elements used as the input). The training set was used to train a machine learning model, in particular the Mixtral-8-7B-lnstruct model. Mixtral is a decoder-only model that operates as a sparse mixture-of-experts network. In this architecture, each layer is composed of 8 feedforward blocks, called “experts”. For every token, at each layer, a router network selects two experts to process the token's information. These selected experts then combine their outputs additively. This methodology allows for an increase in the model's parameter count while effectively controlling computational costs and latency. By utilizing only a fraction of the total set of parameters per token, Mixtral improves performance while managing resource usage efficiently. Mixtral undergoes pretraining using multilingual data, employing a context size of 32k tokens. The used model, Mixtral-8x7B-lnstruct-v0.1, has a size of 16 bits. Mixtral was instructed by a sequence of prompts: • first of all, it was told to act as a forecasting model and to agree on a given format for the input time sequence and for the output it should return; • then, a certain number of examples has been presented to it, in the form of a list of latency values [11,12, ..., 115] followed by the desired predicted output; • finally, the LLM was tested with a series of input samples unseen before. To do a comparative analysis, a simple linear regression model was also trained using as its training set the same examples that were presented to the Mixtral LLM. The particular instance of linear regression model used was the “LinearRegression” model available from the scikit-learn Python library. Figure 6 shows comparison between the target outputs for a series of time points (derived from the original simulated metric measurements) and the corresponding predicted output by the Mixtral mixture-of-experts model. Figure 7 illustrates the same plot for the linear regression model (when both Mixtral and the linear regression model were trained with only 5 training examples). As we can intuitively see from comparing Figures 6 and 7, Mixtral outperforms the linear regression models in reconstructing the sequence of average latency values, when the number of available training examples is very low. This is confirmed by the results shown in Figure 8, showing how the mean squared error varies by varying the size of the training set for both Mixtral (mixtral_mse) and the linear regression model (scikit_mse). When the number of available training sequences increases, the two models converge on the same level of accuracy. An advantage of using a LLM for the forecasting task lies in the fact that, in case we want to perform latency forecasting, it is not needed to train it for that specific task; indeed, it is sufficient to prompt it with a very low number of examples, reaching then a good reconstruction accuracy. Nevertheless, other simpler models such as a linear regression model can also be acceptable with sufficient training examples. Either way, being able to predict future values in a time series of resource utilisation metric values can be useful since the sequence of raw metric values can have many different shapes, depending on how one request flow is contending within the memory system with concurrent flows, and on what resource utilisation control parameters (e.g. levels of priority, bandwidth caps) are assigned by scheduling policy. Using LLMs, it is not needed to put any particular effort into building big and balanced datasets; the model can be used after having collected few samples from the request flow of interest, which makes it much more feasible to implement online training functions to adapt the model at runtime. Hence, these investigations have shown feasibility of the future resource utilisation prediction, which can offer useful input information for more effective resource control algorithms. Concepts described herein may be embodied in computer-readable code for fabrication of an apparatus that embodies the described concepts. For example, the computer-readable code can be used at one or more stages of a semiconductor design and fabrication process, including an electronic design automation (EDA) stage, to fabricate an integrated circuit comprising the apparatus embodying the concepts. The above computer-readable code may additionally or alternatively enable the definition, modelling, simulation, verification and / or testing of an apparatus embodying the concepts described herein. For example, the computer-readable code for fabrication of an apparatus embodying the concepts described herein can be embodied in code defining a hardware description language (HDL) representation of the concepts. For example, the code may define a register-transfer-level (RTL) abstraction of one or more logic circuits for defining an apparatus embodying the concepts. The code may define a HDL representation of the one or more logic circuits embodying the apparatus in Verilog, System Verilog, Chisel, or VHDL (Very High-Speed Integrated Circuit Hardware Description Language) as well as intermediate representations such as FIRRTL. Computer-readable code may provide definitions embodying the concept using system-level modelling languages such as SystemC and SystemVerilog or other behavioural representations of the concepts that can be interpreted by a computer to enable simulation, functional and / or formal verification, and testing of the concepts. Additionally or alternatively, the computer-readable code may define a low-level description of integrated circuit components that embody concepts described herein, such as one or more netlists or integrated circuit layout definitions, including representations such as GDSII. The one or more netlists or other computer-readable representation of integrated circuit components may be generated by applying one or more logic synthesis processes to an RTL representation to generate definitions for use in fabrication of an apparatus embodying the invention. Alternatively or additionally, the one or more logic synthesis processes can generate from the computer-readable code a bitstream to be loaded into a field programmable gate array (FPGA) to configure the FPGA to embody the described concepts. The FPGA may be deployed for the purposes of verification and test of the concepts prior to fabrication in an integrated circuit or the FPGA may be deployed in a product directly. The computer-readable code may comprise a mix of code representations for fabrication of an apparatus, for example including a mix of one or more of an RTL representation, a netlist representation, or another computer-readable definition to be used in a semiconductor design and fabrication process to fabricate an apparatus embodying the invention. Alternatively or additionally, the concept may be defined in a combination of a computer-readable definition to be used in a semiconductor design and fabrication process to fabricate an apparatus and computer-readable code defining instructions which are to be executed by the defined apparatus once fabricated. Such computer-readable code can be disposed in any known transitory computer-readable medium (such as wired or wireless transmission of code over a network) or non-transitory computer-readable medium such as semiconductor, magnetic disk, or optical disc. An integrated circuit fabricated using the computer-readable code may comprise components such as one or more of a central processing unit, graphics processing unit, neural processing unit, digital signal processor or other components that individually or collectively embody the concept. Figure 9 illustrates a simulator implementation that may be used. Whilst the earlier described embodiments implement the present invention in terms of apparatus and methods for operating specific processing hardware supporting the techniques concerned, it is also possible to provide an instruction execution environment in accordance with the embodiments described herein which is implemented through the use of a computer program. Such computer programs are often referred to as simulators, insofar as they provide a software based implementation of a hardware architecture. Varieties of simulator computer programs include emulators, virtual machines, models, and binary translators, including dynamic binary translators. Typically, a simulator implementation may run on a host processor 730, optionally running a host operating system 720, supporting the simulator program 710. In some arrangements, there may be multiple layers of simulation between the hardware and the provided instruction execution environment, and / or multiple distinct instruction execution environments provided on the same host processor. Historically, powerful processors have been required to provide simulator implementations which execute at a reasonable speed, but such an approach may be justified in certain circumstances, such as when there is a desire to run code native to another processor for compatibility or re-use reasons. For example, the simulator implementation may provide an instruction execution environment with additional functionality which is not supported by the host processor hardware, or provide an instruction execution environment typically associated with a different hardware architecture. An overview of simulation is given in “Some Efficient Architecture Simulation Techniques”, Robert Bedichek, Winter 1990 USENIX Conference, Pages 53 - 63. To the extent that embodiments have previously been described with reference to particular hardware constructs or features, in a simulated embodiment, equivalent functionality may be provided by suitable software constructs or features. For example, particular circuitry may be implemented in a simulated embodiment as computer program logic. Similarly, memory hardware, such as a register or cache, may be implemented in a simulated embodiment as a software data structure. In arrangements where one or more of the hardware elements referenced in the previously described embodiments are present on the host hardware (for example, host processor 730), some simulated embodiments may make use of the host hardware, where suitable. The simulator program 710 may be stored on a computer-readable storage medium (which may be a non-transitory medium), and provides a program interface (instruction execution environment) to the target code 700 (which may include applications, operating systems and a hypervisor) which is the same as the interface of the hardware architecture being modelled by the simulator program 710. Thus, the program instructions of the target code 700 described above, may be executed from within the instruction execution environment using the simulator program 710, so that a host computer 730 which does not actually have the hardware features of the apparatus 2 discussed above can emulate these features. Hence, the simulator code 710 may include resource monitoring program logic 712 and future resource utilisation prediction program logic 714 which simulates functionality of the resource monitoring circuitry 30 and future resource utilisation prediction circuitry 32 described earlier. The resource monitoring program logic 712 may obtain a resource utilisation metric indicative of utilisation of processing system resource. The future resource utilisation prediction program logic 714 may predict, based on the resource utilisation metric captured by the resource monitoring program logic 712, at least one future resource utilisation metric indicative of predicted future utilisation of the processing system resource. The future resource utilisation prediction program logic 714 makes the at least one future resource utilisation metric accessible to a system resource management agent. Such a simulator code 710 can be part of a system simulator which simulates the behaviour of a corresponding hardware system 2 (e.g. for the purpose of testing software due to execute on that system 2). In the present application, the words “configured to...” are used to mean that an element of an apparatus has a configuration able to carry out the defined operation. In this context, a “configuration” means an arrangement or manner of interconnection of hardware or software. For example, the apparatus may have dedicated hardware which provides the defined operation, or a processor or other processing device may be programmed to perform the function. “Configured to” does not imply that the apparatus element needs to be changed in any way in order to provide the defined operation. In the present application, lists of features preceded with the phrase “at least one of mean that any one or more of those features can be provided either individually or in combination. For example, “at least one of: [A], [B] and [C]” encompasses any of the following options: A alone (without B or C), B alone (without A or C), C alone (without A or B), A and B in combination 5 (without C), A and C in combination (without B), B and C in combination (without A), or A, B and C in combination. Although illustrative embodiments of the invention have been described in detail herein with reference to the accompanying drawings, it is to be understood that the invention is not limited to those precise embodiments, and that various changes and modifications can be effected 10 therein by one skilled in the art without departing from the scope of the invention as defined by the appended claims.

Claims

1. An apparatus comprising:resource monitoring circuitry configured to obtain a resource utilisation metric indicative of utilisation of processing system resource; andfuture resource utilisation prediction circuitry configured to predict, based on the resource utilisation metric captured by the resource monitoring circuitry, at least one future resource utilisation metric indicative of predicted future utilisation of the processing system resource;wherein the future resource utilisation prediction circuitry is configured to make said at least one future resource utilisation metric accessible to a system resource management agent.

2. The apparatus according to claim 1, in which the resource utilisation metric comprises a memory system utilisation metric indicative of utilisation of memory system resource.

3. The apparatus according to any of claims 1 and 2, in which the resource utilisation metric is indicative of at least one of:latency of requests serviced using the processing system resource;throughput of requests serviced using the processing system resource; and spare resource capacity of the processing system resource.

4. The apparatus according to any preceding claim, in which the resource utilisation metric is indicative of utilisation of a memory system interconnect configured to route memory system requests between one or more requesters and one or more completers.

5. The apparatus according to any preceding claim, in which the future resource utilisation prediction circuitry is configured to operate at runtime to provide a runtime prediction of future utilisation of the processing system resource.

6. The apparatus according to any preceding claim, in which the future resource utilisation prediction circuitry is configured to process time series input data dependent on a plurality of instances of the resource utilisation metric captured at different past times using a prediction model, to predict the at least one future resource utilisation metric for at least one future time.

7. The apparatus according to claim 6, in which each data item of the time series input data comprises a value obtained by applying an aggregate function to a plurality of instances of the resource utilisation metric captured within a respective past time window.

8. The apparatus according to any of claims 6 and 7, in which the prediction model comprisesa machine learning model.

9. The apparatus according to any of claims 6 to 8, in which the prediction model comprises a regression model.

10. The apparatus according to any of claims 6 to 8, in which the prediction model comprises a transformer model.

11. The apparatus according to claim 10, in which the prediction model comprises a decoder-only transformer model.

12. The apparatus according to any of claims 6 to 11, in which the prediction model comprises a mixture-of-experts model.

13. The apparatus according to any of claims 6 to 12, in which the future resource utilisation prediction circuitry comprises model training circuitry to adapt parameters of the prediction model based on a training data set comprising training data items each providing a corresponding set of past resource utilisation metric data and future resource utilisation metric data captured by the resource monitoring circuitry.

14. The apparatus according to any of claims 6 to 13, in which the future resource utilisation prediction circuitry is configured to implement the prediction model using dedicated hardware.

15. The apparatus according to any of claims 6 to 13, in which the future resource utilisation prediction circuitry comprises processing circuitry configured to execute software implementing the prediction model.

16. The apparatus according to any preceding claim, in which, for at least one control setting: the resource monitoring circuitry is configured to obtain a workload-specific resource utilisation metric indicative of utilisation of the processing system resource by a specific processing workload; andthe future resource utilisation prediction circuitry is configured to obtain the at least one future resource utilisation metric indicative of predicted future utilisation of the processing system resource by the specific processing workload.

17. The apparatus according to any preceding claim, comprising resource control circuitry to control allocation of memory system resource to a given processing workload, based on at leastone configurable resource control parameter configurable at runtime by the system resource management agent.

18. The apparatus according to claim 17, in which the system resource management agent is configured to determine a control setting for the at least one configurable resource control parameter based on the at least one future resource utilisation metric.

19. The apparatus according to any preceding claim, in which the future resource utilisation prediction circuitry is configured to make said at least one future resource utilisation metric accessible to the system resource management agent by writing the at least one future resource utilisation metric to a software-accessible storage location.

20. The apparatus according to any preceding claim, in which the system resource management agent comprises software executed by processing circuitry.

21. The apparatus according to any of claims 1 to 19, in which the system resource management agent comprises memory system resource control circuitry implemented in hardware.

22. Computer-readable code for fabrication of the apparatus according to any preceding claim.

23. A computer program comprising instructions which, when executed by a host data processing apparatus, control the host data processing apparatus to provide an instruction execution environment for execution of target program code, the computer program comprising: resource monitoring program logic configured to obtain a resource utilisation metric indicative of utilisation of processing system resource; andfuture resource utilisation prediction program logic configured to predict, based on the resource utilisation metric captured by the resource monitoring program logic, at least one future resource utilisation metric indicative of predicted future utilisation of the processing system resource;wherein the future resource utilisation prediction program logic is configured to make said at least one future resource utilisation metric accessible to a system resource management agent.

24. A method comprising:obtaining a resource utilisation metric indicative of utilisation of processing system resource;predicting, based on the resource utilisation metric, at least one future resource utilisation metric indicative of predicted future utilisation of the processing system resource; andmaking said at least one future resource utilisation metric accessible to a system resource management agent.

Images