|
From: | Tao Xu |
Subject: | Re: [PATCH v13 06/12] numa: Extend CLI to provide memory latency and bandwidth information |
Date: | Fri, 25 Oct 2019 14:33:53 +0800 |
User-agent: | Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 |
On 10/23/2019 11:28 PM, Igor Mammedov wrote:
On Sun, 20 Oct 2019 19:11:19 +0800 Tao Xu <address@hidden> wrote:
[...]
Eric suggest me to drop picoseconds. So here I can use ns. For bandwidth, if we use B/s here, does it let user or developer to misunderstand that the smallest unit is B/s ?+# +# @access-bandwidth: access bandwidth (MB/s) +# +# @read-bandwidth: read bandwidth (MB/s) +# +# @write-bandwidth: write bandwidth (MB/s)I think units here are not appropriate, values stored in fields are minimal base units only and nothing else (i.e. ps and B/s)
@item -numa node[,mem=@var{size}][,cpus=@var{firstcpu}[-@var{lastcpu}]][,nodeid=@var{node}][,initiator=@var{initiator}] @itemx -numa node[,memdev=@var{id}][,cpus=@var{firstcpu}[-@var{lastcpu}]][,nodeid=@var{node}][,initiator=@var{initiator}] @itemx -numa dist,src=@var{source},dst=@var{destination},val=@var{distance} @itemx -numa cpu,node-id=@var{node}[,socket-id=@var{x}][,core-id=@var{y}][,thread-id=@var{z}] +@itemx -numa hmat-lb,initiator=@var{node},target=@var{node},hierarchy=@var{str},data-type=@var{str}[,latency=@var{lat}][,bandwidth=@var{bw}]^^^ ^^^ Using the same 'str' for 2 different enums is confusing. Suggest for 1st use 'level' and for the second just 'type'
Ok
@findex -numa Define a NUMA node and assign RAM and VCPUs to it. Set the NUMA distance from a source node to a destination node. +Set the ACPI Heterogeneous Memory Attributes for the given nodes.Legacy VCPU assignment uses @samp{cpus} option where@var{firstcpu} and @var{lastcpu} are CPU indexes. Each @@ -256,6 +259,50 @@ specified resources, it just assigns existing resources to NUMA nodes. This means that one still has to use the @option{-m}, @option{-smp} options to allocate RAM and VCPUs respectively.+Use @samp{hmat-lb} to set System Locality Latency and Bandwidth Information+between initiator and target NUMA nodes in ACPI Heterogeneous Attribute Memory Table (HMAT). +Initiator NUMA node can create memory requests, usually including one or more processors.s/including/it has/+Target NUMA node contains addressable memory. + +In @samp{hmat-lb} option, @var{node} are NUMA node IDs. @var{str} of 'hierarchy' +is the memory hierarchy of the target NUMA node: if @var{str} is 'memory', the structure +represents the memory performance; if @var{str} is 'first-level|second-level|third-level', +this structure represents aggregated performance of memory side caches for each domain. +@var{str} of 'data-type' is type of data represented by this structure instance: +if 'hierarchy' is 'memory', 'data-type' is 'access|read|write' latency(nanoseconds)is nanoseconds is right here? Looking at previous patches default value of suffix-less should be picoseconds. I'd just drop '(nanoseconds)'. User will use appropriate suffix.
OK, I will drop it.
+or 'access|read|write' bandwidth(MB/s) of the target memory; if 'hierarchy' isditto (MB/s), probably should be Bytes/s for default suffix-less value (well, I'm not sure how to express it better)
But last version, we let !QEMU_IS_ALIGNED(node->bandwidth, MiB) as error.
+'first-level|second-level|third-level', 'data-type' is 'access|read|write' hit latency +or 'access|read|write' hit bandwidth of the target memory side cache. + +@var{lat} of 'latency' is latency value, the possible value and units are +NUM[ps|ns|us] (picosecond|nanosecond|microsecond), the recommended unit is 'ns'. @var{bw} +is bandwidth value, the possible value and units are NUM[M|G|T], mean that+the bandwidth value are NUM MB/s, GB/s or TB/s. Note that max NUM is 65534, +if NUM is 0, means the corresponding latency or bandwidth information is not provided. +And if input numbers without any unit, the latency unit will be 'ps' and the bandwidth +will be MB/s.1st: above is applicable to both bw and lat values and should be documented as such 2nd: 'max NUM is 65534' when different suffixes is fleeting target, spec says that entry with 0xFFFF is unreachable, so how about documenting unreachable value as 0xFFFFFFFFFFFFFFFF (then CLI parsing code will exclude it from range detection and acpi table building code translate it to internal 0xFFFF it could fit into the tables)
If we input 0xFFFFFFFFFFFFFFFF, qemu will raise error that parameter expect a size value.
[Prev in Thread] | Current Thread | [Next in Thread] |