Re: [Qemu-devel] [PATCH RESEND v8 09/11] numa: Extend the CLI to provide memory latency and bandwidth information

[Tao Xu]

On 8/7/2019 7:14 AM, Daniel Black wrote:
> Liu Jingqi, Tao Xu,
>
> Apologies to the late response on a patch on what is already a v8 patch.
>
> The specification of latency and bandwidth is very much following the
> ACPI specification.
>
> For a qemu interface I think this should be in more human measurements
> (time for latency and a bandwidth rate for the bandwidth).
>
> e.g rather than
>   -object memory-backend-ram,size=64M,id=m0
>   -object memory-backend-ram,size=64M,id=m1geosync
>   -numa node,nodeid=0,memdev=m0
>   -numa node,nodeid=1,memdev=m1geosync,initiator=0
>   -numa cpu,node-id=0,socket-id=0
>   -numa cpu,node-id=0,socket-id=1
>   -numa
> hmat-lb,initiator=0,target=0,hierarchy=memory,data-type=access-latency,base-lat=1000,latency=5
>   -numa
> hmat-lb,initiator=0,target=0,hierarchy=memory,data-type=access-bandwidth,base-bw=20,bandwidth=5
>   -numa
> hmat-lb,initiator=0,target=1,hierarchy=memory,data-type=access-latency,base-lat=100,latency=10
>   -numa
>   
> hmat-lb,initiator=0,target=1,hierarchy=memory,data-type=access-bandwidth,base-bw=20,bandwidth=10
>
>
> Suggest a form like:
>
>   -numa
> hmat-lb,initiator=0,target=0,hierarchy=memory,data-type=access-latency,latency=NUM[fpnm[s]]
>   -numa
> hmat-lb,initiator=0,target=0,hierarchy=memory,data-type=access-bandwidth,bandwidth=NUM[KMGP][Bb[ps]]
>
> So:
>
>   -numa
> hmat-lb,initiator=0,target=0,hierarchy=memory,data-type=access-latency,latency=5ns
>   -numa
> hmat-lb,initiator=0,target=0,hierarchy=memory,data-type=access-bandwidth,bandwidth=5Gb
>
>
> So this would remove the base-[lt,bw] settings and compute those internally in 
> qemu based on latency/bandwidth specified with real units.
>
> Also note the linux kernel HMAT latency display doesn't match up with the 
> parameters passed in this patch series. Not sure which is at fault.
>
> Test and results:
>
> x86_64-softmmu/qemu-system-x86_64 -machine pc -nographic   -smp
> 2,sockets=2 -m 128M,slots=2,maxmem=1G
> -kernel /home/dan/repos/linux/vmlinux  -append "console=ttyS0"
> -object memory-backend-ram,size=64M,id=m0 -object
> memory-backend-ram,size=64M,id=m1geosync -numa node,nodeid=0,memdev=m0
> -numa node,nodeid=1,memdev=m1geosync,initiator=0 -numa
> cpu,node-id=0,socket-id=0 -numa cpu,node-id=0,socket-id=1 -numa
> hmat-lb,initiator=0,target=0,hierarchy=memory,data-type=access-latency,base-lat=1000,latency=5
> -numa
> hmat-lb,initiator=0,target=0,hierarchy=memory,data-type=access-bandwidth,base-bw=20,bandwidth=5
> -numa
> hmat-lb,initiator=0,target=1,hierarchy=memory,data-type=access-latency,base-lat=100,latency=10
> -numa
> hmat-lb,initiator=0,target=1,hierarchy=memory,data-type=access-bandwidth,base-bw=20,bandwidth=10
>
> The Booting from ROM..[    0.000000] Linux version 5.3.0-rc2+
> (dan@volution) (gcc version 9.1.1 20190503 (Red Hat 9.1.1-1) (GCC)) #21
> SMP Tue Aug 6 17:15:49 AEST 2019
>
>
> [    0.419303] HMAT: Memory Flags:0001 Processor Domain:0 Memory Domain:0
> [    0.419648] HMAT: Memory Flags:0001 Processor Domain:0 Memory Domain:1
> [    0.419956] HMAT: Locality: Flags:00 Type:Access Latency Initiator Domains:1 
> Target Domains:2 Base:1000
> [    0.420527]   Initiator-Target[0-0]:5 nsec
> [    0.420791]   Initiator-Target[0-1]:10 nsec
> [    0.421068] HMAT: Locality: Flags:00 Type:Access Bandwidth Initiator 
> Domains:1 Target Domains:2 Base:20
> [    0.421447]   Initiator-Target[0-0]:100 MB/s
> [    0.421635]   Initiator-Target[0-1]:200 MB/s
This is because the base-lat is only first set is valid, so if we input 
different base-lat like the test case, we follow the first 1000, so 
result is 5000 ps = 5 ns. but your suggestion is reasonable, this is not 
user-friendly. So we will refer to your suggestions. Thank you!