Maintaining samples identifying a metric

Abstract

An apparatus for maintaining samples identifying a metric comprises processing circuitry configured to perform processing operations associated with one or more processes, each of the processes associ

Description

The present disclosure relates to data processing. Furthermore, the present disclosure relates to an apparatus, a method, and a computer program. Some apparatuses associated identifiers with processes. The identifier can then be used when monitoring a metric to associate the monitoring with the identifier. According to a first aspect of the present techniques there is provided an apparatus comprising: processing circuitry configured to perform processing operations associated with one or more processes, each of the one or more processes associated with an identifier; sampling circuitry configured to maintain, for the identifier, information indicative of a plurality of samples, each of the plurality of samples identifying a metric associated with the identifier; and monitoring circuitry configured to perform a determination of whether the metric identified by a given sample of the plurality of samples maintained for the identifier falls outside of a dynamically varying range and, in response to the determination indicating that the metric identified in the given sample falls outside of the dynamically varying range, to generate a software visible indication associated with the identifier. According to a second aspect of the present techniques there is provided a method comprising: performing processing operations associated with one or more processes, each of the one or more processes associated with an identifier; maintaining, for the identifier, information indicative of a plurality of samples, each of the plurality of samples identifying a metric associated with the identifier; and performing a determination of whether the metric identified by a given sample of the plurality of samples maintained for the identifier falls outside of a dynamically varying range; and in response to the determination indicating that the metric identified in the given sample falls outside of the dynamically varying range, generating a software visible indication associated with the identifier. According to a third aspect of the present techniques there is provided a computer program for controlling a host data processing apparatus to provide an instruction execution environment comprising: processing program logic configured to perform processing operations associated with one or more processes, each of the one or more processes associated with an identifier; sampling program logic configured to maintain, for the identifier, information indicative of a plurality of samples, each of the plurality of samples identifying a metric associated with the identifier; and monitoring program logic configured to perform a determination of whether the metric identified by a given sample of the plurality of samples maintained for the identifier falls outside of a dynamically varying range and, in response to the determination indicating that the metric identified in the given sample falls outside of the dynamically varying range, to generate a software visible indication associated with the identifier. According to some configurations of the present techniques the computer program is stored on a computer readable storage medium. According to some configurations of the present techniques the computer readable storage medium is a non-transitory computer readable storage medium. The present techniques will be described further, by way of example only, with reference to configurations thereof as illustrated in the accompanying drawings, in which: Figure 1 schematically illustrates an apparatus according to some configurations of the present techniques; Figure 2 schematically illustrates an apparatus according to some configurations of the present techniques; Figure 3 schematically illustrates a memory system according to some configurations of the present techniques; Figure 4 schematically illustrates an apparatus according to some configurations of the present techniques; Figure 5 shows an example of different software execution environments executed by the processing circuitry; Figure 6 illustrates an example of allocating partition identifiers to different software execution environments; Figure 7 shows an example of control registers for controlling which partition identifier is specified for a given memory transaction; Figure 8 schematically illustrates a metric according to some configurations of the present techniques; Figure 9 schematically illustrates an apparatus according to some configurations of the present techniques; Figure 10 schematically illustrates an apparatus according to some configurations of the present techniques; Figure 11 schematically illustrates an apparatus according to some configurations of the present techniques; Figure 12 schematically illustrates a sequence of steps carried out according to some configurations of the present techniques; Figure 13 schematically illustrates a sequence of steps carried out according to some configurations of the present techniques; and Figure 14 schematically illustrates a simulator implementation according to some configurations of the present techniques. According to some configurations of the present techniques there is provided an apparatus comprising processing circuitry configured to perform processing operations associated with one or more processes, each of the one or more processes associated with an identifier. The apparatus is also provided with sampling circuitry configured to maintain, for the identifier, information indicative of a plurality of samples, each of the plurality of samples identifying a metric associated with the identifier. The apparatus is also provided with monitoring circuitry configured to perform a determination of whether the metric identified by a given sample of the plurality of samples maintained for the identifier falls outside of a dynamically varying range and, in response to the determination indicating that the metric identified in the given sample falls outside of the dynamically varying range, to generate a software visible indication associated with the identifier. For an apparatus, e.g., a data processing apparatus, provided with processing circuitry, the processing circuitry can be configured to perform processing operations, e.g., the execution of one or more instructions. In some use cases, the processing operations can be associated with a single process. However, in some use cases, the processing operations may be associated with plural processes. The processing operations that are performed for each of the one or more processes may be processing operations defined by an instruction set architecture (ISA). An instruction set architecture comprises a complete set of instructions that a programmer or a compiler can use to control processing circuitry. Instructions within an instruction set architecture may include instructions to cause the processing circuitry to perform arithmetic or logical operations to manipulate data items and / or instructions to cause the processing circuitry to interact with one or more other items of circuitry, e.g., a memory hierarchy, in order to retrieve data items to be used in subsequent processing operations, or to return result data items to the memory hierarchy. Where multiple (i.e., plural) processes are running on processing circuitry, either in parallel using duplicated circuit elements within the processing circuitry, or sequentially utilising one set of circuit elements for a share of a total available processing time (for example, measured in clock cycles), requests, e.g., memory access requests, or requests to utilise one or more functional blocks of circuitry may be issued at different rates by different ones of the processes. Some processes may require heavy use of resources whilst others may make less use, or no use, of other circuit elements. In such circumstances, ensuring a fair share of usage can be difficult for the processing circuitry as it may not have a complete picture of the usage and / or availability of resources. The association of an identifier with a process or with processes enables the sampling circuitry and the monitoring circuitry to monitor the usage of resources by a process (or processes) associated with the particular identifier. The identifier may be the only identifier assigned to the process or may be one of a plurality of identifiers assigned to the process. The identifier may be one of a plurality of possible identifiers with different ones of the plurality of possible identifiers assigned to different processes or groups of processes. By maintaining samples identifying a metric indicating a usage of resources, and by associating that metric with the identifier, it is possible to determine whether processes associated with that identifier are using greater than their fair share of resources, and / or whether processes associated with that identifier are using far fewer resources than may be expected, which may be an indication that processes other than those associated with the identifier are monopolising resources. Such monitoring could, for example, include monitoring a value of the metric and notifying software if / when it is determined that the metric exceeds a particular threshold value associated with that identifier. The inventors of the present techniques have recognised that, whilst a comparison to a statically defined threshold can provide an indication of a process that is either over utilising, or underutilising resources, setting such a static threshold can be difficult as an appropriate choice of threshold may depend on overall system usage and resources available, which may not be known to a programmer or a compiler in advance of the process being run on the processing circuitry. The apparatus is therefore arranged to compare each sample, i.e., each given sample from the plurality of samples that are maintained for a given identifier, against a dynamically varying range. The provision of a dynamically varying range allows the monitoring circuitry to adapt for different resource usage and different resource availability. Further details on the dynamically varying range will be provided below. The monitoring circuitry is arranged to identify when the metric identified in the given sample falls outside the dynamically varying range, and in response to the metric falling outside the dynamically varying range, to generate a software visible indication to enable software, for example, privileged software operating on the processing circuitry to identify that processes associated with the identifier are behaving outside of their normal behaviour. The software may then take a decision on whether to take any action in relation to the indication. Making use of a dynamically varying range, either in addition to or as an alternative to a static threshold, allows for the monitoring circuitry to identify when processes executing on the processing circuitry are behaving outside of their standard behaviour, or outside of a range of standard behaviours according to a current state of the processing circuitry and the processes executing on that processing circuitry. Whilst the dynamically varying range may be defined globally, e.g., based on an overall usage of one or more resources associated with the processing circuitry by all processes, or by a subset of the processes, in some configurations the dynamically varying range is defined based on the plurality of samples for the identifier. In other words, for each given identifier, the monitoring circuitry determines the dynamically varying range from previous samples that for that given identifier. The plurality of samples provides an indication of how the metric has varied between different samples, e.g., a chronological record of the value of the metric over a plurality of sample windows. The metric identified in each of the samples can therefore be used to determine a behaviour of the metric for the identifier. Basing the dynamically varying range on the identifier, e.g., such that the dynamically varying range is derived from the plurality of samples for that identifier, enables the dynamic range to be tailored at runtime for each given identifier. The dynamically varying range may be based solely on the plurality of samples for the identifier, or the dynamically varying range may also be based on samples associated with a different identifier enabling the dynamically varying range to take advantage of the global variation in parameters. The monitoring circuitry can make use of any property of the metric to define the dynamically varying range. For example, the dynamically varying range may be based on an extremum value (e.g., a maximum and / or a minimum) of the metric recorded over the plurality of samples, and / or a value estimated through extrapolation of one or more of the plurality of previous samples. In some configurations the monitoring circuitry is configured to calculate an average of the metric identified in each of the plurality of samples maintained for the identifier and the dynamically varying range is defined based on the average. The average may be the mean, i.e., a non-weighted average calculated, for example, by taking the values of the metric identified in each of the plurality of samples, summing the values and dividing by the number of samples. Alternatively, a weighted average may be used in which more recent samples are weighted differently to older samples. In some configurations the sampling circuitry maintains a number of samples equal to a power of 2, i.e., 2N samples where N is an integer. In such configurations, the division by 2N can be performed by right shifting the binary representation of the sum by N places, thereby reducing the complexity of the circuitry used to calculate the mean. In some configurations the dynamically varying range comprises values that fall within a threshold distance of the average. The threshold distance may be statically defined, for example, the threshold distance may be hardwired into the circuitry. Alternatively, the threshold distance may be a software configurable threshold and / or may be based on one or more further global or identifier specific metrics. For example, the threshold distance may be defined as a percentage of a total range of metric values sampled for the identifier. In some configurations the monitoring circuitry is configured to calculate a variance of the metric identified in each of the plurality of samples maintained for the identifier, and the dynamically varying range is defined based on the variance. The variance may be calculated as the squared deviation from the average of the samples maintained for the identifier, i.e., the square of the standard deviation. In other words, where the average is calculated as the sum of the metric across all samples divided by the number of samples, the variance may be defined by taking a difference between the metric in each sample and the average, summing the square of the differences, and dividing by the number of samples. As discussed, in some configurations the sampling circuitry maintains a number of samples equal to a power of 2, i.e., 2N samples where N is an integer. In such configurations, the division by 2N can be performed by right shifting the binary representation of the sum by N places, thereby reducing the complexity of the circuitry used to calculate the variance. In some configurations the threshold distance is proportional to the variance. For example, the threshold distance may be set to be equal to the variance or to an integer multiple of the variance. In some configurations, the threshold distance may be set equal to the standard deviation (i.e., the square route of the variance) or to an integer multiple of the standard deviation. In some configurations, the integer multiple is a multiple of two and may be calculated by performing a left shift of a binary representation of the variance. As discussed, the precise definition of the dynamically varying range may be determined differently in different implementations. In some configurations the determination comprises performing a calculation of a difference between the given sample and the average, and dividing the difference by the variance to determine a score; and the determination indicates that the samples falls outside of the dynamically varying range when a magnitude of the score exceeds a score threshold. In other words, the metric indicated in the given sample may be considered to be an outlier when the given value is greater than or equal to a predefined number of variances outside of the mean, where the predefined number of variances is set by the score threshold. In some configurations the score threshold may take a first threshold value for given values greater than the average and a second value for given values less than the average. The first value and the second value may be different in magnitude. In some configurations, only one of the first threshold and the second threshold may be used. Whilst the raw values of the average and the variance may be used, in some configurations the monitoring circuitry is configured to multiply at least one of the average and the variance by a corresponding scale factor prior to performing the calculation. The scale values may be hardwired into the monitoring circuitry or may be software configurable. In some configurations the apparatus is provided with a configuration register configured to be software accessible and arranged to store the corresponding scale factor. The register may store both a corresponding scale factor for the variance and a corresponding scale factor for the average. Alternatively, only one of the two corresponding scale factors may be stored. In some configurations the scale factor may be a power of two such and the scaling by the scale factor can be implemented as a shift applied to the average or the variance. For example, the scale factor may be 2N where the exponent N is stored in the software accessible register and indicates the number of places by which to right shift the average or the variance. The software visible indication may take a variety of different forms. In some configurations the monitoring circuitry is configured to issue an interrupt as the software visible indication. The interrupt may be issued by the monitoring circuitry and received by the processing circuitry. On receipt of the interrupt, the processing circuitry may interrupt the current processing activities and pass to an interrupt handler which may be provided in software. In this way the software can quickly be made available when a process (or processes) associated with an identifier fall outside of the dynamically varying range. In some configurations the monitoring circuitry is configured to store an indication of the identifier in a software accessible location as the software visible indication. The software accessible location can then be polled, for example, by higher privileged software operating on the processing apparatus to determine whether any metrics have been identified as falling outside of the dynamically varying range. This approach provides a passive mechanism for the monitoring circuitry to indicate that the dynamically varying range has been exceeded and allows the processing circuitry to continue the current processing operations. In some configurations, the monitoring circuitry is configurable to switch between issuing an interrupt or storing an indication of the identifier in the software accessible location, for example, according to a software accessible configuration parameter. In some configurations the software accessible location comprises at least one of: a register; and a region of memory. The region of memory may be a specifically defined region of memory accessible by software having a particular privilege level. Whilst the identifiers may have a one to one association with processes being executed by the processing circuitry, in some configurations the identifier is a group identifier shared between a plurality of processes. Using a group identifier allows a greater amount of data to be obtained for each identifier and reduces the overall number of identifiers that need to be monitored improving the overall system efficiency. In some configurations the apparatus is provided with a range control register, wherein the dynamically varying range is defined based on at least one parameter defined in the range control register. As discussed, the parameter may be, e.g., a scaling value, and or a sequence of weights to be applied to the sampled values. Whilst the at least one parameter value may be specified as at least one global parameter, in some configurations the at least one parameter is specified on a per identifier basis. In some configurations the metric defines at least one of: a bandwidth usage by processes associated with the identifier; a latency experienced by processes associated with the identifier; a utilisation of a storage structure for data requested by processes associated with the identifier; and a quality of service metric measured for processes associated with the identifier. The dynamically varying range may therefore correspond to a range of expect values for the metric. As a result, the monitoring circuitry is able to identify when the apparatus is operating outside of normal operating conditions in relation to that metric. In some configurations each sample includes a plurality of metrics and the monitoring circuitry is configured to determine if any of the plurality of metrics fall outside of a dynamically varying range defined for that metric. In some configurations the identifier is one of a plurality of identifiers; and the sampling circuitry is configured to maintain the information indicative of the plurality samples for each of the plurality of identifiers associated with one or more corresponding processes. The information indicative of the plurality of samples may be stored in storage circuitry specific to the samples, for example, a set of registers provided within the monitoring circuitry. Alternatively, or in addition, the information indicative of the plurality of samples may be stored in a region of memory accessible to higher privileged software. The monitoring circuitry may be configured to monitor samples for plural identifiers at any given time. In some configurations the sampling circuitry is configured to obtain the plurality of samples over a sequence of sampling windows. For example, the metric may be obtained by counting a number of instances of requests made by, or on behalf of processes associated with a particular identifier over the course of each of the sampling windows. The sampling circuitry may then provide an indication of the metric to the monitoring circuitry. Whilst the identifier may be any identifier that can be used to distinguish one or a group or processes, e.g., a workload distinguishing identifier, in some configurations the identifier comprises at least one of a partition identifier; and a performance monitoring group identifier. A partition identifier (PARTID) is typically used to control resource allocation to a process, for example, to determine which set of resource allocation settings are applied by resource allocation control circuitry of a memory system component. On the other hand, a performance monitoring group (PMG) identifier is typically used by monitoring circuitry for monitoring of processes identified by that PMG identifier, for example, to select which of several workload-specific resource utilisation metrics are to be updated based on the memory access request. In some configurations, the PARTID and PMG may be considered independent identifiers. 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 (e.g. caps on maximum cache allocation or maximum bandwidth consumption) and for selection of which resource utilisation metric to update. Some configurations of the invention will now be described with reference to the accompanying figures. Figure 1 schematically illustrates an apparatus 200 according to some configurations of the present techniques. The apparatus 200 is provided with processing circuitry 201, sampling circuitry 202, and monitoring circuitry 203. The processing circuitry 201 is arranged to perform processing operations according to a received sequence of instructions. The sequence of instructions includes instructions that form part of one or more processes. Where instructions from plural processes are being executed by the processing circuitry 201 the processing circuitry may process the instructions from multiple processes in parallel, for example, using duplicated hardware. Alternatively, the processing circuitry 201 may process the instructions in sequence with each of the processes being scheduled for processing by the processing circuitry 201 during a fraction of the available clock cycles. Each process that is processed by the processing circuitry 201 is associated with an identifier. The identifier is used by the monitoring circuitry 203 for monitoring of processes identified by that identifier to allow the monitoring circuitry to maintain samples of a metric specific to workloads which are associated with that identifier. As discussed, multiple processes may share one identifier and metrics associated with plural identifiers may be sampled and monitored in parallel. The sampling circuitry 202 is arranged to maintain information indicative of a plurality of samples associated with the identifier. In other words, the sampling circuitry 202 is configured to monitor a particular metric, e.g., a resource usage metric, and to capture information indicative of the particular metric for processes that are associated with the identifier. For example, where the metric being monitored is a bandwidth metric for memory accesses, the sampling circuitry 202 may be configured to identify requests submitted for memory accesses and to identify a number of requests, or an amount of data requested, by processes that include the identifier. The sampling circuitry 202 records and maintains multiple of these samples for each identifier. The monitoring circuitry 203 is configured to monitor the samples to determine whether the metric identified in the samples falls within a dynamically varying range. The dynamically varying range provides an indication of an expected range of values that the metric identified by the samples should fall within. The monitoring circuitry 203 performs a determination to determine if the identifier is within the dynamically varying range or if it is outside of the dynamically varying range. If the monitoring circuitry 203 determines that the samples falls outside of the dynamically varying range, then the monitoring circuitry 203 generates a software visible indication associated with the identifier (i.e., a software visible indication identifying the particular identifier for which the sample fell outside of the dynamically varying range). Where the metric identified in the sample does not fall outside the dynamically varying range, the dynamically varying range may be updated to include the information in the sample. For example, the sampling circuitry 202 may replace a previous oldest maintained sample with the new sample. Alternatively, the sampling circuitry 202 and / or the monitoring circuitry 203 may update information indicative of the dynamically varying range to incorporate the metric indicated in the sample. Figure 2 schematically illustrates an example of an apparatus 2 according to some configurations of the present techniques. The apparatus 2 comprises N processing clusters 4 (where N is 1 or more), where each processing cluster includes one or more processing elements 6 such as a CPU (central processing unit) or GPU (graphics processing unit). Each processing element 6 may have at least one cache, e.g. a level 1 data cache 8, level 1 instruction cache 10 and shared level 2 cache 12. It will be appreciated that this is just one example of a possible cache hierarchy and other cache arrangements could be used. The processing elements 6 within the same cluster are coupled by a cluster interconnect 14. The cluster interconnect 14 may have a cluster cache 16 for caching data accessible to any of the processing elements. A system on chip (SoC) interconnect 18 couples the N clusters and any other requester devices 22 (such as display controllers or direct memory access (DMA) controllers). The SoC interconnect may have a system cache 20 for caching data accessible to any of the requesters connected to it. The SoC interconnect 18 controls coherency between the respective caches 8, 10, 12, 16, 20 according to any known coherency protocol. The SoC interconnect is also coupled to one or more memory controllers 24, each for controlling access to a corresponding memory 25, such as DRAM or SRAM. The SoC interconnect 18 may also direct transactions to other completer devices, such as a crypto unit for providing encryption / decryption functionality. Hence, the data processing system 2 comprises a memory system for storing data and providing access to the data in response to transactions issued by the processing elements 6 and other requester devices 22. The caches 8, 10, 12, 16, 20, the interconnects 14, 18, memory controllers 24 and memory devices 25 can each be regarded as a component of the memory system. Other examples of memory system components may include memory management units or translation lookaside buffers (either within the processing elements 6 themselves or further down within the system interconnect 18 or another part of the memory system), which are used for translating memory addresses used to access memory, and so can also be regarded as part of the memory system. In general, a memory system component may comprise any component of a data processing system used for servicing memory transactions for accessing memory data or controlling the processing of those memory transactions. The memory system may have various resources available for handling memory transactions. For example, the caches 8, 10, 12, 16, 20 have storage capacity available for caching data required by a given software execution environment executing on one of the processing elements 6, to provide quicker access to data or instructions than if they had to be fetched from main memory 25. Similarly, Memory Management Units (MMUs) and / or Translation Lookaside Buffers (TLBs) may have capacity available for caching address translation data. Also, the interconnects 14, 18, the memory controller 24 and the memory devices 25 may each have a certain amount of bandwidth available for handling memory transactions. When multiple software execution environments executing on the processing elements 6 share access to the memory system, it can be desirable to prevent one software execution environment using more than its fair share of resource, to prevent other execution environments perceiving a loss of performance. This can be particularly important for data centre (server) applications where there is an increasing demand to reduce capital expenditure by increasing the number of independent software processes which interact with a given amount of memory capacity, to increase utilisation of the data centre servers. Nevertheless, there will still be a demand to meet web application tail latency objectives and so it is undesirable if one process running on the server can monopolise memory system resources to an extent that other processes suffer. Similarly, for networking applications, it is increasingly common to combine multiple functions onto a single SoC which previously would have been on separate SoCs. This again leads to a desire to limit performance interactions between software execution environments, and to monitor how those need to allow those independent processes to access the shared memory while limiting performance interactions. Figure 3 schematically illustrates an example of partitioning the control of allocation of memory system resources in dependence on the software execution environment which issues the corresponding memory transactions. In this context, a software execution environment may be any process, or part of a process, executed by a processing element within a data processing system. For example, a software execution environment may comprise an application, a guest operating system or virtual machine, a host operating system or hypervisor, a security monitor program for managing different security states of the system, or a sub-portion of any of these types of processes (e.g. a single virtual machine may have different parts considered as separate software execution environments). As shown in figure 3, each software execution environment may be allocated a given partition identifier (PartID) 30 which is passed to the memory system components along with memory transactions that are associated with that software execution environment. The partition identifier is an example of an identifier. Within the memory system component, resource allocation or contention resolution operations can be controlled based on one of a number of sets of memory system component parameters selected based on the partition identifier. For example, as shown in figure 3, each software execution environment may be assigned an allocation threshold (an example of a predefined limit) representing a maximum amount of cache capacity that can be allocated for data / instructions associated with that software execution environment, with the relevant allocation threshold when servicing a given transaction being selected based on the partition identifier associated with the transaction. For example, in figure 3 transactions associated with partition identifier 0 may allocate data to up to 50% of the cache’s storage capacity, leaving at least 50% of the cache available for other purposes. Similarly, in a memory system component such as the memory controller 24 which has a finite amount of bandwidth available for servicing memory transactions, minimum and / or maximum bandwidth thresholds may be specified for each partition identifier. A memory transaction associated with a given partition identifier can be prioritised if, within a given period of time, memory transactions specifying that partition identifier have used less than the minimum amount of bandwidth, while a reduced priority can be used for a memory transaction if the maximum bandwidth has already been used or exceeded for transactions specifying the same partition identifier. These control schemes will be discussed in more detail below. It will be appreciated that these are just two examples of ways in which control of memory system resources can be partitioned based on the software execution environment that issued the corresponding transactions. In general, by allowing different processes to “see” different partitioned portions of the resources provided by the memory system, this allows performance interactions between the processes to be limited to help address the problems discussed above. It will be appreciated that the PARTID illustrated in figure 3 is only provided as an example of a possible identifier. The skilled person will appreciate that the identifier may also be provided, for example, as a performance monitoring group (PMG) identifier. The PMG identifier, as will be described in further detail below, is typically used by monitoring circuitry for monitoring of processes identified by that PMG identifier, for example, to select which of several workload-specific resource utilisation metrics are to be updated based on the memory access request. A same PMG identifier may be shared between multiple processes. In some example configurations a PMG identifier may be shared between multiple processes which are also each associated with (identified by) their own PARTID. The PMG identifier may be provided for the purpose of monitoring whilst the PARTID may be provided for the purpose of allocation of resources, for example, for allocation of a share of a cache. The partition identifier, or PMG identifier, associated with memory transactions can be used to partition performance monitoring within the memory system, so that separate sets of performance monitoring data can be tracked for each partition identifier or for each PMG identifier, to allow information specific to a given software execution environment (or group of software execution environments) to be identified so that the source of potential performance interactions can be identified more easily than if performance monitoring data was recorded across all software execution environments as a whole. This can also help diagnose potential performance interaction effects and help with identification of possible solutions. An architecture is discussed below for controlling the setting of partition identifiers and PMG identifiers, labelling of memory transactions based on the partition identifier set for a corresponding software execution environment, routing the partition identifiers through the memory system, and providing partition-based controls at a memory system component in the memory system. This architecture is scalable to a wide range of uses for the partition identifiers. The use of the partition identifiers is intended to layer over the existing architectural semantics of the memory system without changing them, and so addressing, coherence and any required ordering of memory transactions imposed by the particular memory protocol being used by the memory system would not be affected by the resource / performance monitoring partitioning. When controlling resource allocation using the partition identifiers or PMG identifiers, while this may affect the performance achieved when servicing memory transactions for a given software execution environment, it does not affect the result of an architecturally valid computation. That is, the partition identifier or PMG identifier does not change the outcome or result of the memory transaction (e.g. what data is accessed), but merely affects the timing or performance achieved for that memory transaction. Figure 4 schematically illustrates an example of the processing element 6 in more detail. The processor includes a processing pipeline including a number of pipeline stages, including a fetch stage 40 for fetching instructions from the instruction cache 10, a decode stage 42 for decoding the fetched instructions, an issue stage 44 comprising an issue queue 46 for queueing instructions while waiting for their operands to become available and issuing the instructions for execution when the operands are available, an execute stage 48 comprising a number of execute units 50 for executing different classes of instructions to perform corresponding processing operations, and a write back stage 52 for writing results of the processing operations to data registers 54. Source operands for the data processing operations may be read from the registers 54 by the execution stage 48. In this example, the execute stage 48 includes an ALU (arithmetic / logic unit) for performing arithmetic or logical operations, a floating point (FP) unit for performing operations using floating-point values and a load / store unit for performing load operations to load data from the memory system into registers 54 or store operations to store data from registers 54 to the memory system. It will be appreciated that these are just some examples of possible execution units and other types could be provided. Similarly, other examples may have different configurations of pipeline stages. For example, in an out-of-order processor, an additional register renaming stage may be provided for remapping architectural register specifiers specified by instructions to physical register specifiers identifying registers 54 provided in hardware, as well as a reorder buffer for tracking the execution and commitment of instructions executed in a different order to the order in which they were fetched from the cache 10. Similarly, other mechanisms not shown in figure 4 could still be provided, e.g. branch prediction functionality. The processing element 6 has a number of control registers 60, including for example a program counter register 62 for storing a program counter indicating a current point of execution of the program being executed, an exception level register 64 for storing an indication of a current exception level at which the processor is executing instructions, a security state register 66 for storing an indication of whether the processing element 6 is in a non-secure or a secure state, and memory partitioning and monitoring (MPAM) control registers 68 for controlling memory system resource and performance monitoring partitioning (the MP AM control registers are discussed in more detail below). It will be appreciated that other control registers could also be provided. The processing element 6 has a memory management unit (MMU) 70 for controlling access to the memory system in response to memory transactions. For example, when encountering a load or store instruction, the load / store unit issues a corresponding memory transaction specifying a virtual address. The virtual address is provided to the memory management unit (MMU) 70 which translates the virtual address into a physical address using address mapping data stored in a translation lookaside buffer (TLB) 72. Each TLB entry may identify not only the mapping data identifying how to translate the address, but also associated access permission data which defines whether the processor is allowed to read or write to addresses in the corresponding page of the address space. In some examples there may be multiple stages of address translation and so there may be multiple TLBs, for example a stage 1 TLB providing a first stage of translation for mapping the virtual address generated by the load / store unit 50 to an intermediate physical address, and a stage 2 TLB providing a second stage of translation for mapping the intermediate physical address to a physical address used by the memory system to identify the data to be accessed. The mapping data for the stage 1 TLB may be set under control of an operating system, while the mapping data for the stage 2 TLB may be set under control of a hypervisor, for example, to support virtualisation. While, for conciseness, figure 4 shows the MMU being accessed in response to data accesses being triggered by the load / store unit, the MMU may also be accessed when the fetch stage 40 requires fetching of an instruction which is not already stored in the instruction cache 10, or if the instruction cache 10 initiates an instruction prefetch operation to prefetch an instruction into the cache before it is actually required by the fetch stage 40. Hence, virtual addresses of instructions to be executed may similarly be translated into physical addresses using the MMU 70. In addition to the TLB 72, the MMU may also comprise other types of cache, such as a page walk cache 74 for caching data used for identifying mapping data to be loaded into the TLB during a page table walk. The memory system may store page tables specifying address mapping data for each page of a virtual memory address space. The TLB 72 may cache a subset of those page table entries for a number of recently accessed pages. If the processing element 6 issues a memory transaction to a page which does not have corresponding address mapping data stored in the TLB 72, then a page table walk is initiated. This can be relatively slow because there may be multiple levels of page tables to traverse in memory to identify the address mapping entry for the required page. To speed up page table walks, recently accessed page table entries of the page table can be placed in the page walk cache 74. These would typically be page table entries other than the final level page table entry which actually specifies the mapping for the required page. These higher level page table entries would typically specify where other page table entries for corresponding ranges of addresses can be found in memory. By caching at least some levels of the page table traversed in a previous page table walk in the page walk cache 74, page table walks for other addresses sharing the same initial part of the page table walk can be made faster. Alternatively, rather than caching the page table entries themselves, the page walk cache 74 could cache the addresses at which those page table entries can be found in the memory, so that again a given page table entry can be accessed faster than if those addresses had to be identified by first accessing other page table entries in the memory. Figure 5 shows an example of different software execution environments which may be executed by the processing element 6. In this example the architecture supports four different exception levels EL0 to EL3 increasing in privilege level (so that EL3 has the highest privilege exception level and EL0 has the lowest privilege exception level). In general, a higher privilege level has greater privilege than a lower privilege level and so can access at least some data and / or carry out some processing operations which are not available to a lower privilege level. Applications 80 are executed at the lowest privilege level ELO. A number of guest operating systems 82 are executed at privilege level ELI with each guest operating system 82 managing one or more of the applications 80 at ELO. A virtual machine monitor, also known as a hypervisor or a host operating system, 84 is executed at exception level EL2 and manages the virtualisation of the respective guest operating systems 82. Transitions from a lower exception level to a higher exception level may be caused by exception events (e.g. events required to be handled by the hypervisor may cause a transition to EL2), while transitions back to a lower level may be caused by return from handling an exception event. Some types of exception events may be serviced at the same exception level as the level they are taken from, while others may trigger a transition to a higher exception state. The current exception level register 64 indicates which of the exception levels ELO to EL3 the processing element 6 is currently executing code in. In this example the system also supports partitioning between a secure domain 90 and a normal (less secure) domain 92. Sensitive data or instructions can be protected by allocating them to memory addresses marked as accessible to the secure domain 90 only, with the processor having hardware mechanisms for ensuring that processes executing in the less secure domain 92 cannot access the data or instructions. For example, the access permissions set in the MMU 70 may control the partitioning between the secure and non-secure domains, or alternatively a completely separate security memory management unit may be used to control the security state partitioning, with separate secure and non-secure MMUs 70 being provided for sub-control within the respective security states. Transitions between the secure and normal domains 90, 92 may be managed by a secure monitor process 94 executing at the highest privilege level EL3. This allows transitions between domains to be tightly controlled to prevent non-secure operations 80 or operating systems 82 for example accessing data from the secure domain. In other examples, hardware techniques may be used to enforce separation between the security states and police transitions, so that it is possible for code in the normal domain 92 to branch directly to code in the secure domain 90 without transitioning via a separate secure monitor process 94. However, for ease of explanation, the subsequent description below will refer to an example which does use the secure monitor process 94 at EL3. Within the secure domain 90, a secure world operating system 96 executes at exception level ELI and one or more trusted applications 98 may execute under control of that operating system 96 at exception level ELO. In this example there is no exception level EL2 in the secure domain 90 because virtualisation is not supported in the secure domain, although it would still be possible to provide this if desired. An example of an architecture for supporting such a secure domain 90 may be the Trustzone architecture provided by ARM® Limited of Cambridge, UK. Nevertheless, it will be appreciated that other techniques could also be used. Some examples could have more than two security states, providing three or more states with different levels of security associated with them. The security state register 66 indicates whether the current domain is the secure domain 90 or the non-secure 92 and this indicates to the MMU 70 or other control units what access permissions to use to govern whether certain data can be accessed or operations are allowed. Figure 5 shows a number of different software execution environments 80, 82, 84, 94, 96, 98 which can be executed on the system. Each of these software execution environments can be allocated a given partition identifier (e.g., a partition ID or PARTID), or a group of two or more software execution environments may be allocated a common identifier. In some cases, individual parts of a single processes (e.g. different functions or sub-routines) can be regarded as separate execution environments and allocated separate identifiers. For example, Figure 6 shows an example where virtual machine VM 3 and the two applications 3741, 3974 executing under it are all allocated PARTID 1, a particular process 3974 executing under a second virtual machine, VM 7, is allocated PARTID 2, and the VM7 itself and another process 1473 running under it is allocated PARTID 0. It is not necessary to allocate a bespoke partition ID to every software execution environment. A default partition ID may be specified to be used for software execution environments for which no dedicate partition ID has been allocated. The control of which parts of the partition ID space are allocated to each software execution environment is carried out by software at a higher privilege level, for example a hypervisor running at EL2 controls the allocation of partitions to virtual machine operating systems running at ELL However, in some cases the hypervisor may permit an operating system at a lower privilege level to set its own partition IDs for parts of its own code or for the applications running under it. Also, in some examples the secure world 90 may have a completely separate partition ID space from the normal world 92, controlled by the secure world OS or monitor program EL3. Figure 7 shows an example of the MP AM control registers 68. The MP AM control registers 68 include a number of partition ID registers 100 (also known as MP AM system registers) each corresponding to a respective operating state of the processing circuitry. In this example the partition ID registers 100 include registers MPAM0EL1 to MPAM3 EL3 corresponding the respective exception levels EL0 to EL3 in the non-secure domain 92, and an optional additional partition ID register MPAMI ELI S corresponding to exception level ELI in the secure domain 90. In this example, there is no partition ID register provided for EL0 in the secure domain, as it is assumed that the trusted applications 98 in the secure domain are tied closely to the secure world operating system 96 that runs those applications 98 and so they can be identified with the same partition ID. However, in other implementations a separate partition ID register could be provided for EL0 in the secure world. Each partition ID register 100 comprises fields for up to three partition IDs as shown in table 1 below: Table 1: ID Name Description PARTIDD Partition ID used for data requests. PARTID I Partition ID used for instruction requests. PMG Performance monitoring group ID. Table 2 below summarises which partition ID register 100 is used for memory transactions executed in each operating state, and which operating states each partition ID register 100 are controlled from (that is, which operating state can update the information specified by that register): Table 2: Partition ID register 100 Controlled From Controls IDs When Executing In Notes (explained in more detail below) MPAM0EL1 NSELl NS_EL0 when PLKELO in MPAM1EL1 = 0 (Applications) MPAM0EL1 IDs can be remapped with virtualization option. Can be overridden by MPAM1 ELI control bit, PLKELO. MPAM1EL1 NS_EL2 NSELl NSELl (Guest OS) NS_EL0 when PLKELO = 1 MPAM1EL1 IDs can be remapped with virtualization option. Can override MPAMOELL If NS EL2 not implemented, MPAM1EL1 is controlled by NSELL If NS EL2 is implemented, MPAM1EL1 may be controlled from NS EL2 if MPAM2EL2.EL1 WRINH is 1, or from NS_EL2 and NSELl if MPAM2 EL2.EL1 WRINH is 0. MPAM2EL2 EL3 NS_EL2 NS_EL2 (Hypervisor) If EL3 is not implemented or MP AM secure option not implemented, MPAM2 EL2 is only controlled from NS EL2. MPAM1EL1 _S (optional - if not provided, MPAM1EL1 can be used for controlling IDs in SELl and SELO) EL3 SELl SELl SELO (secure) MPAM1EL1S may be controlled from EL3 if MPAM3 EL3 EL1S WRIN H is 1, or from EL3 and S ELl if MPAM3 EL3 EL1S WRIN HisO. MPAM3EL3 EL3 EL3 MPAM3 EL3 is controlled from EL3. The naming convention MPAMxEly for the partition ID registers indicates that the partition IDs specified in the partition ID register MPAMxELy are used for memory transactions issued by the processing circuitry 6 when in operating state ELx and that state ELy is the lowest exception level at which that partition ID register MPAMxELy can be accessed. However, when the current exception level is ELO in the non-secure domain, MPAM0EL1 can be overridden - when a configuration value PLKELO set in MPAM-EL1 is set to 1 the partition IDs in MPAM1EL1 are used when executing in NS_EL0. Hence, the control for ELI can override the control for ELO when desired. This can be useful for constraining all applications running under a particular virtual machine to use the same partition ID to avoid needing to update MPAM0EL1 each time there is a context switch between applications within the same virtual machine. While the configuration parameter PLK ELO is described as being stored in MPAM1EL1 in this example (the partition ID register corresponding to the higher exception level which sets that configuration parameter), it could also be stored in another control register. In general, when switching between different processes executed at the same state (e.g. different applications at ELO or different guest operating systems at ELI), an exception event triggers a switch to a higher exception state where the process running at that state (e.g. the operating system at ELI or the hypervisor at EL2) then updates the partition IDs in the relevant partition ID register 100 before returning processing to the lower exception state to allow the new process to continue. Hence, the partition IDs associated with a given process may effectively be seen as part of the context information associated with that process, which is saved and restored as part of the architectural state of the processor when switching from or to that process. However, by providing multiple partition ID registers 100 corresponding to the different operating states of the system, it is not necessary to update the contents of a single partition ID register each time there is a change in operating state at times other than at a context switch, such as when an operating system (OS) traps temporarily to the hypervisor for the hypervisor to carry out some action before returning to the same OS. Such traps to the hypervisor may be fairly common in a virtualised system, e.g. if the hypervisor has to step in to give the OS a different view of physical resources than what is actually provided in hardware. Hence, by providing multiple partition ID registers 100, labelling of memory system transactions with partition IDs automatically follows changes of the exception level or of the secure / non-secure state, so that there is faster performance as there is no need to update the partition IDs each time there is a change in exception level or security state. Also, providing separate secure and less secure partition ID registers can be preferable for security reasons, by preventing a less secure process inferring information about the secure domain from the partition IDs used, for example. However, banking partition ID registers per security state is optional, and other embodiments may provide only a single version of a given partition ID register shared between the secure and less secure domains (e.g. MPAM1EL1 can be used, with MPAM1EL1S being omitted). In this case, the monitor code executed at EL3 may context switch the information in the partition ID register when switching between the secure and less secure domains. Also, in general the control information, such as the partition IDs and any associated configuration information, specified within the partition ID register 100 associated with a given operating state is set in response to instructions executing at a higher exception level than the exception level associated with that partition ID register 100. However, again this general premise can be overridden for some of the registers, where the higher exception level code may set a configuration parameter EL1_WRINH, EL2_WRINH or EL1SWRINH which controls whether code executing at a given operating state may set its own partition IDs in the corresponding partition ID register. That is, the WRINH configuration values specify whether a given execution environment is allowed to set the partition IDs allocated to itself. While the examples below show the WRINH flag for controlling setting of the partition IDs by a given exception level being stored in the partition ID register 100 associated with the next highest exception level, alongside the partition IDs for that exception level, it will be appreciated that these flags could also be stored in a separate control register. More particularly, Table 3 lists the information included in each partition ID register 100, and Table 4 summarises which states each partition ID register 100 can be read or written from. Some of the registers 100 include information specific to that register as shown. Table 3: Which PARTID register 100? Field Name Description all PARTID I Partition ID for instruction accesses all PARTID D Partition ID for data accesses all PMG Performance monitoring group ID MPAM1EL1 PLKEL0 PLK EL0 locks the PARTID used at NS_EL0 to be the same as the PARTID used atNS_ELl. MPAM1EL1S (optional - if not provided then PLK EL0 in MPAM1EL1 controls locking of the PARTID used at EL0 for both the S and NS states) PLKEL0 PLK EL0 locks the PARTID used at S ELO to be the same as the PARTID used atSELl. MPAM2EL2 EL1WRINH If 1, writes to MPAM1EL1 from NSELl trap to NS_EL2. MPAM3EL3 EL2WRINH If 1, writes to MPAM2 EL2 from NS_EL2 trap to EL3. MPAM3EL3 EL1SWRINH (optional -provided if MPAM1EL1S is provided) If 1, writes to MPAM1EL1S from SELl are trapped to EL3. Table 4: PARTID register 100 EL0 NSELl SELl EL2 EL3 MPAM0EL1 R RW RW RW RW MPAM1EL1 - R(W*) - RW RW MPAM2EL2 - - - R(W*) RW MPAM3EL3 - - - - RW MPAM1EL1S - - R(W*) - RW Where the asterisks indicate that: • MPAM1EL1 can be written from NSELl when EL1WRINH in MPAM2EL2 = 0, but when EL1WRINH = 1 then writes to MPAM1EL1 from NS ELl trap to EL2; • MPAM2EL2 can be written from EL2 when EL2WRINH in MPAM3EL3 = 0, but when EL2WRINH = 0 then writes to MPAM2EL2 from EL2 trap to EL3; • MPAM1EL1S can be written from SELl when ELISWRINH in MPAM3 EL3 = 0, but when ELI S WRINH = 1 then writes to MPAM1EL1S from S ELl trap to EL3. Hence, an attempt to set the partition ID register 100 from within the same exception state when not allowed by a higher exception state causes an exception event which triggers a switch to that higher exception state. An exception handler at the higher exception state can then decide how the partition ID should be set. Note that in the alternative embodiment described above where MPAM EL1S is omitted, MPAM1EL1 would be R(W*) accessible from both NS ELl and S ELl (with EL1WRINH controlling whether write access is possible from ELI), and the ELI S WRINH configuration parameter can be omitted from register MPAM3 EL3. In general, when a memory transaction is generated by the processing circuitry 6, one of the partition ID registers 100 is selected based on the current operating state as specified above. If the memory transaction is for accessing an instruction, the transaction is tagged with a partition ID derived from the PARTIDI field of the selected partition ID register. Page table walk memory transactions triggered by a miss in the TLB 72 for an instruction access would use the same partition ID as the instruction access. If the memory transaction is for accessing data, then the transaction is tagged with a partition ID derived from the PARTIDD field of the selected partition ID register 100 (and again any page table walk access triggered by the MMU following a data access would use the same partition ID as the data access itself). Note that regardless of whether the MMU issuing a page table walk access itself supports resource / performance monitoring partitioning based on the partition ID, it may still append the relevant PARTID D or PARTIDI identifier to the corresponding memory transaction to allow memory system components in another part of the memory system to perform such partitioning. The PARTID D and PARTID I fields of a given partition ID register may be set to the same partition ID or to different partition IDs. It can be useful to allow separate partition IDs to be defined for the data and instruction accesses for the same software execution environment, so that different resource control parameters can be used for the corresponding instruction and data accesses. An alternative approach would be to have a single partition ID associated with a software execution environment as a whole, but to append an additional bit of 0 or 1 depending on whether the access is for instructions or data, and this would allow the memory system component to select different control parameters for the instruction and data accesses respectively. However, for a given number of sets of control parameters selected based on the partition ID, this approach would mean that there would have to be a 50-50 split of the partition ID space between data and instructions. In practice, it may often be desirable to have more data partitions than instruction partitions, because it can be relatively common for multiple software execution environments to use the same code but execute with different data inputs, and so it can be particularly useful to be able to share a single instruction partition ID among multiple software execution environments while allowing each of those environments to use different data partitions. The approach of appending a 0 or 1 bit to indicate instruction on data accesses would in that circumstance require multiple sets of identical configuration information to be defined at the memory system component for each separate instance of the common code. In contrast, by providing separate instruction and data partition fields in the partition ID register 100, where the instruction and data partition IDs are selected from a common ID space, it is possible to reuse the same partition ID between different software execution environments and to partition the partition ID space between data and instructions as required without constraining this to a fifty-fifty split. Even though some additional storage capacity may be required for two partition ID fields in each partition ID register 100, this approach can save resource at the memory system component since by sharing one partition between the instruction accesses of multiple execution environments, fewer sets of control parameters (and hence less storage) are required at the memory system component. Regardless of whether the transaction is for an instruction or data access, the transaction is also tagged with a performance monitoring partition ID derived from the PMG field of the selected partition ID register 100. This enables memory system components to partition performance monitoring, e.g. by using the performance monitoring ID of the memory transaction as part of the criteria for determining whether a given performance monitor should be updated in response to the memory transaction. In one embodiment, the PMG field may be treated as completely independent of the PARTIDD and PARTID I fields. In this case, memory system components implementing performance monitoring may determine whether a memory transaction causes an update of a given performance monitor in dependence on the performance monitoring partition ID only, independent of the data / instruction partition ID included in the same memory transaction. This would provide the advantage that different partitions for instruction / data accesses could nevertheless share the same performance monitoring ID, which would support gathering of combined performance statistics for a number of processes which require different instruction / data access configurations at a memory system component. Hence, by specifying a performance monitoring group ID separate from the partition IDs used for controlling resource allocation at the memory system component, this allows multiple different software execution environments to be tracked using a common set of performance counters even if their resources are being allocated separately. Alternatively, another approach may be to interpret the PMG field as a suffix to be appended to the corresponding partition ID derived from the PARTID D or PARTIDI fields. With this approach, when a transaction is issued to memory, the transaction is appended with two IDs, one based on the selected PARTID I or PARTIDD fields, and another based on the PMG field, but the PMG field is regarded as a property of the instruction / data partition ID rather than an ID in its own right. Hence, memory system components can in this case perform resource partitioning based on a first partition ID derived from PARTID I or PARTID D, but perform performance monitoring partitioning based on the combination of the first partition ID and a second partition ID derived from PMG. With this approach, it is no longer possible for different instruction / data partition IDs to share the same performance monitoring ID, but the advantage is that a shorter PMG field can be used to save hardware cost as the PMG field does not need to distinguish all possible performance monitoring partitions - only the partitions that share the same instruction / data partition ID are distinguished by the PMG field. For example, this can allow a 1 or 2-bit PMG field to be used rather than a larger field, which saves cost not only in the control registers 68 but also in the wires which carry the memory transactions through the memory system. In some embodiments, separate PMG suffix fields PMG D and PMG I could be provided corresponding to the PARTID D and PARTID I fields respectively, to allow separate performance monitoring group properties to be defined for data and instruction accesses respectively. Either way, the ability to define multiple performance monitoring partitions per data / instruction partition ID can be useful. On the other hand, it will be appreciated that other examples could omit the separate performance monitoring ID field altogether, and instead use the same partition ID to control both the management of resources and the performance monitoring. Figure 8 schematically illustrates an example of a metric sampled by sampling circuitry 202 in accordance with some configurations of the present techniques. The sampling circuitry 202 takes a plurality of samples of a metric for a given identifier, for example, the sample 213. The samples are taken at intervals and information indicative of the samples is stored in order to maintain an indication of an average metric 211 and a dynamic range of the metric having an upper bound 210 and a lower bound 212. The information indicative of the samples is stored for a number of most recent samples. The average metric 211 is calculated based on the average metric of each of the stored samples. The upper bound 210 and the lower bound 212 are calculated based on the variance of the stored samples. The upper bound 210 is set to the average metric 211 plus an integer multiple of the variance. The lower bound 212 is set to the average metric 211 minus the integer multiple of the variance. Samples falling within the dynamically varying range, i.e., samples for which the metric measured in those samples is less than or equal to the upper bound 210, and more than or equal to the lower bound 212 are considered to be within the expected range for the given identifier. Samples falling outside of the dynamically varying range, i.e., samples for which the metric is greater than the upper bound 210 or for which the metric is lower than the lower bound 212 are considered to be outside of the expected range for the identifier. For example, the sample 214 indicates a metric value that is greater than the upper bound 210 and, as a result is outside of the dynamically varying range. The monitoring circuitry 203 is configured to identify such outliers through comparison of the metric indicated in the sample 214 against the upper bound 210 and the lower bound 212 and is configured to generate a software visible indication of the outlying sample 214. Figure 9 schematically illustrates an apparatus configured to perform a determination of whether to generate a software visible indication according to some configurations of the present techniques. The apparatus maintains a plurality of samples 220 including samples SO to S7. Each of the plurality of samples is indicative of a metric sampled by sampling circuitry 202. The samples 220 are provided to mean calculation circuitry 221 which calculates the mean (average) of the metric indicated in the samples 220. In particular, the mean calculation circuitry 221 calculates the sum of the metrics indicated in the samples 220 and divides the sum by eight. Because eight samples are maintained and eight is a power of two, the division can be achieved by right shifting the binary representation of the sum by 3 places. The mean calculation circuitry outputs the mean to difference circuitry 222. The difference circuitry 222 receives the mean calculated by the mean calculation circuitry 221 along with a value of a metric indicated in a new sample. The difference circuitry 222 determines a difference between the metric indicated in the new sample and the mean received from the mean calculation circuitry 211. The difference calculated by the difference calculation circuitry 222 is then passed to comparison circuitry 224. The comparison circuitry 224 receives the difference calculated by the difference calculation circuitry 222 and compares the absolute value of the difference to a threshold 223. When the difference exceeds the threshold 223, then the comparison circuitry 224 causes a software visible indication to be generated. In addition, the new sample is added to the plurality of samples 220. The addition of the new sample 220 causes the oldest (least recently received) sample to be evicted from the plurality of samples. Hence, when a subsequent sample is received, the samples comprised in the plurality of samples represent an up to date indication of the metric. Figure 10 schematically illustrates an alternative arrangement of an apparatus configured to perform a determination of whether to generate a software visible indication according to some configurations of the present techniques. The apparatus maintains a plurality of samples 220 and is provided with mean calculation circuitry 221, difference calculation circuitry 222, a threshold 223 and comparison circuitry 224 as described in relation to figure 9. The mean calculation circuitry 221 operates as described in relation to figure 9 but, in addition, the mean output by the mean calculation circuitry 221 is provided to variance computation circuitry 225 along with the metric indicated in each of the plurality of samples 220. The variance calculation circuitry 225 is provided in addition to the threshold 223 and is used to generate a dynamically varying threshold that is dependent on the value of the metric stored in each of the plurality of samples. The variance calculation circuitry determines a difference between the metric in each of the plurality of samples 220 and the mean provided by the mean calculation circuitry 221. The variance output by the variance calculation circuitry 225 is then provided as a sum of the squares of these differences. The variance that is output by the variance calculation circuitry 224 is provided to the comparison circuitry 224. The comparison circuitry 224 compares the absolute value of the difference to the variance generated by the variance generation circuitry 225. When the comparison circuitry 224 determines that the absolute value of the difference exceeds the mean by a threshold 223, the comparison circuitry 224 causes a software visible indication to be generated. As described in relation to figure 9, the new sample is added to the plurality of samples 220. The addition of the new sample 220 causes the oldest (least recently received) sample to be evicted from the plurality of samples. Hence, when a subsequent sample is received, the samples comprised in the plurality of samples represent an up to date indication of the metric. Figure 11 schematically illustrates an alternative arrangement of an apparatus configured to perform a determination of whether to generate a software visible indication according to some configurations of the present techniques. The apparatus maintains a plurality of samples 220 and is provided with mean calculation circuitry 221, difference calculation circuitry 222, comparison circuitry 224 and variance calculation circuitry 225 as described in relation to figures 9 and 10. In addition, the apparatus is provided with first scaling circuitry 227 and second scaling circuitry 228 along with a threshold 229. The threshold 229 and the first scaling circuitry 227 and the second scaling circuitry 228 are provided in a software accessible storage structure 230 so that appropriately privileged software, for example, an operating system, can configure the threshold 229 and first and second scale values used by the first scaling circuitry 227 and the second scaling circuitry 228. The first scaling circuitry 227 is provided between the mean calculation circuitry 221 and the difference calculation circuitry 222. The first scaling circuitry acts to scale the mean by a first scale value which is maintained in a software configurable register. The second scaling circuitry 228 is provided at the output of the variance calculation circuitry 225 to cause the variance to be scaled by a second scale value which is maintained in a software configurable register. The difference calculated by the difference calculation circuitry 222 and the scaled variance are passed to division circuitry 226. The division circuitry 226 divides the difference by the scaled variance. The output of the division circuitry 226 is passed to comparison circuitry 224. The comparison circuitry 224 compares the output of the division circuitry 226 to the threshold 229 which is maintain in software configurable storage. When the comparison circuitry 224 determines that the absolute value of the difference exceeds the mean by a threshold amount, the comparison circuitry 224 issues an interrupt to indicate to higher privileged software that the monitoring has detected a sample having a metric that falls outside of the dynamic range. As described in relation to figures 9 and 10, the new sample is added to the plurality of samples 220. The addition of the new sample 220 causes the oldest (least recently received) sample to be evicted from the plurality of samples. Hence, when a subsequent sample is received, the samples comprised in the plurality of samples represent an up to date indication of the metric. The provision of scale values and the threshold in software configurable registers provides control and flexibility over when the software visible indication, e.g., an interrupt, is generated. It will be readily apparent to the skilled person that the arrangement of circuitry set out in the above figures is for illustrative purpose only and that alternative arrangements of circuitry could be provided either to implement a different method of calculating whether or not to generate the software visible indication based on the plurality of samples, or to implement the same algorithm as described in relation to figure 11 but using a different arrangement of hardware. For example, rather than performing a division of the difference by the scaled variance, the threshold 229 could be multiplied by the scaled variance. Mathematically, this will result in the same outcome but avoids the need to perform a computationally expensive division operation. Figure 12 schematically illustrates a sequence of steps according to some configurations of the present techniques. Flow begins at step S120 where processing operations are performed. The processing operations are associated with one or more processes and each process is associated with an identifier. Flow then proceeds to step S121 where sample information identifying a metric associated with an identifier is maintained. Flow then proceeds to step S122 where a determination is performed of whether a given sample maintained for an identifier falls outside of a dynamically varying range. Flow then proceeds to step S123 where it is determined if the sample falls outside of the dynamic range. If, at step S123, it is determined that the sample does not fall outside of the dynamic range, then flow returns to step S120. If, at step S123, it is determined that the sample does fall outside of the dynamic range, then flow proceeds to step S124 where a software visible indication associated with the identifier is generated. Figure 13 schematically illustrates a sequence of steps according to some configurations of the present techniques. Flow begins at step S130. Flow then proceeds to step S131 where samples are obtained. Each of the samples is indicative of a metric associated with an identifier. The metric is updated throughout a sampling window in order to determine, over that sampling window, the metric for each identifier observed by the sampling circuitry during that sampling window. Flow then proceeds to step SI32, where it is determined if the sampling window has ended. If, at step SI32, it is determined that the sampling window has not ended, then flow returns to step S131. If, at step SI32, it is determined that the sampling window has ended, then flow proceeds to step S133. At step S133 a variable i is set to zero. Flow then proceeds to step S134 where the sample obtained during the sampling window for the i-th identifier is compared against the dynamic range for the i-th identifier. Flow then proceeds to step S135 where it is determined if the sample is within the dynamic range for the i-th identifier. If, at step S135, it is determined that the sample is in the dynamic range for the i-th identifier, then flow proceeds to step SI36 where the dynamic range for the i-th identifier is updated based on the sample for the i-th identifier. Flow then proceeds to step S137. If, at step S135, it is determined that the sample was not within the dynamic range, then flow proceeds to step S138. At step S138 a software visible indication (e.g., an interrupt) associated with the i-th identifier is generated before flow proceeds to step S137. At step S137 it is determined if there are any more identifiers to consider. If, at step S137, it is determined that there are no more identifiers to consider, then flow returns to step S131. If, at step S137, it is determined that there are more identifiers to consider, then flow proceeds to step S139 where the variable i is incremented before flow returns to step SI34. It will be readily apparent to the skilled person that the sequence of steps set out in figure 13 are for illustrative purpose only and that some steps may be performed in parallel or out of sequence. For example, rather than looping over all identifiers using the variable i, the determination can be performed for all identifiers in parallel or for a subset of the identifiers in parallel. Furthermore, once the software visible indication is generated in step S138, flow could proceed to step SI36 (rather than step SI37 as illustrated in figure 133) so that the dynamic range is updated to also include the sample that fell outside of the dynamic range. Figure 14 schematically 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 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 apparatuses described in relation to figures 1 to 13 above. For example, the simulator code 710 may comprise processing program logic 711 configured to perform processing operations associated with one or more processes, each of the one or more processes associated with an identifier. The simulator code 710 may also include sampling program logic 712 configured to maintain, for the identifier, information indicative of a plurality of samples, each of the plurality of samples identifying a metric associated with the identifier. Furthermore, the simulator code 710 may include monitoring program logic 713 configured to perform a determination of whether the metric identified by a given sample of the plurality of samples maintained for the identifier falls outside of a dynamically varying range and, in response to the determination indicating that the metric identified in the given sample falls outside of the dynamically varying range, to generate a software visible indication associated with the identifier. In brief overall summary there is provided an apparatus a method and a computer program. The apparatus comprises processing circuitry configured to perform processing operations associated with one or more processes, each of the one or more processes associated with an identifier. The apparatus comprises sampling circuitry configured to maintain, for the identifier, information indicative of a plurality of samples, each of the plurality of samples identifying a metric associated with the identifier. The apparatus comprises monitoring circuitry configured to perform a determination of whether the metric identified by a given sample of the plurality of samples maintained for the identifier falls outside of a dynamically varying range and, in response to the determination indicating that the metric identified in the given sample falls outside of the dynamically varying range, to generate a software visible indication associated with the identifier. 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 (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 configurations 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 configurations, and that various changes, additions and modifications can be effected therein by one skilled in the art without departing from the scope of the invention as defined by the appended claims. For example, various combinations of the features of the dependent claims could be made with the features of the independent claims without departing from the scope of the present invention.

Claims

1. An apparatus comprising:processing circuitry configured to perform processing operations associated with one or more processes, each of the one or more processes associated with an identifier;sampling circuitry configured to maintain, for the identifier, information indicative of a plurality of samples, each of the plurality of samples identifying a metric associated with the identifier; andmonitoring circuitry configured to perform a determination of whether the metric identified by a given sample of the plurality of samples maintained for the identifier falls outside of a dynamically varying range and, in response to the determination indicating that the metric identified in the given sample falls outside of the dynamically varying range, to generate a software visible indication associated with the identifier.

2. The apparatus of claim 1, wherein the dynamically varying range is defined based on the plurality of samples for the identifier.

3. The apparatus of claim 1 or claim 2, wherein the monitoring circuitry is configured to calculate an average of the metric identified in each of the plurality of samples maintained for the identifier and the dynamically varying range is defined based on the average.

4. The apparatus of claim 3, wherein the dynamically varying range comprises values that fall within a threshold distance of the average.

5. The apparatus of claim 4, wherein the monitoring circuitry is configured to calculate a variance of the metric identified in each of the plurality of samples maintained for the identifier, and the dynamically varying range is defined based on the variance.

6. The apparatus of claim 5, wherein the threshold distance is proportional to the variance.

7. The apparatus of any of claims 5 or 6, wherein:the determination comprises performing a calculation of a difference between the given sample and the average, and dividing the difference by the variance to determine a score; andthe determination indicates that the samples falls outside of the dynamically varying range when a magnitude of the score exceeds a score threshold.

8. The apparatus of claim 7, wherein the monitoring circuitry is configured to multiply at least one of the average and the variance by a corresponding scale factor prior to performing the calculation.

9. The apparatus of claim 8, comprising a configuration register configured to be software accessible and arranged to store the corresponding scale factor.

10. The apparatus of any preceding claim, wherein the monitoring circuitry is configured to issue an interrupt as the software visible indication.

11. The apparatus of any preceding claim, wherein the monitoring circuitry is configured to store an indication of the identifier in a software accessible location as the software visible indication.

12. The apparatus of any claim 11, wherein the software accessible location comprises at least one of:a register; anda region of memory.

13. The apparatus of any preceding claim, wherein the identifier is a group identifiershared between a plurality of processes.

14. The apparatus of any preceding claim, comprising a range control register, wherein the dynamically varying range is defined based on at least one parameter defined in the range control register.

15. The apparatus of claim 14, wherein the at least one parameter is specified on a per identifier basis.

16. The apparatus of any preceding claim, wherein the metric defines at least one of: a bandwidth usage by processes associated with the identifier;a latency experienced by processes associated with the identifier;a utilisation of a storage structure for data requested by processes associated with the identifier; anda quality of service metric measured for processes associated with the identifier.

17. The apparatus of any preceding claim, wherein:the identifier is one of a plurality of identifiers; andthe sampling circuitry is configured to maintain the information indicative of the plurality samples for each of the plurality of identifiers associated with one or more corresponding processes.

18. The apparatus of any preceding claim, wherein the sampling circuitry is configured to obtain the plurality of samples over a sequence of sampling windows.

19. The apparatus of any preceding claim, wherein the identifier comprises at least one of:a partition identifier; anda performance monitoring group identifier.

20. A method comprising:performing processing operations associated with one or more processes, each of the one or more processes associated with an identifier;maintaining, for the identifier, information indicative of a plurality of samples, each of the plurality of samples identifying a metric associated with the identifier; andperforming a determination of whether the metric identified by a given sample of the plurality of samples maintained for the identifier falls outside of a dynamically varying range; andin response to the determination indicating that the metric identified in the given sample falls outside of the dynamically varying range, generating a software visible indication associated with the identifier.

21. A computer program for controlling a host data processing apparatus to provide an instruction execution environment comprising:processing program logic configured to perform processing operations associated with one or more processes, each of the one or more processes associated with an identifier;sampling program logic configured to maintain, for the identifier, information indicative of a plurality of samples, each of the plurality of samples identifying a metric associated with the identifier; andmonitoring program logic configured to perform a determination of whether the metric identified by a given sample of the plurality of samples maintained for the identifier falls outside of a dynamically varying range and, in response to the determination indicating that the metric identified in the given sample falls outside of the dynamically varying range, to generate a software visible indication associated with the identifier.

Images