QEMU has been recently split into sub-components and as a one-time operation to avoid breakage of tools, we are setting the QEMU sub-component of this BZ to "General". Please review and change the sub-component if necessary the next time you review this BZ. Thanks

Please try test sequence from https://bugzilla.redhat.com/show_bug.cgi?id=1729077#c8

Tried with slow trian (win2019)
detail steps according to https://bugzilla.redhat.com/show_bug.cgi?id=1729077

it cannot increase the performance evidently.

without flag, 5497
with    flag, 5729


Thanks
Yu Wang

Just like https://bugzilla.redhat.com/show_bug.cgi?id=1729077#c17 please try with other
hv_* flags (compare 'all' and 'all but hv_vapic'), the result is supposed to be a bit
better.

Test with "all flags", "all but hv_vapic" and "none flag".

Results are as below:

                   all         all but hv_vapic      none
Win2019        5217/5309         5763/6023         4291/4293


So, it's almost the same with "all" and "all but hv_vapic", but it 
is higher performance than "none flag".
(almost the same as fasttrain)


qemu-kvm-2.12.0-98.module+el8.2.0+5698+10a84757.x86_64
kernel-4.18.0-179.el8.x86_64
seabios-1.13.0-1.module+el8.2.0+5520+4e5817f3.x86_64

Thanks
Yu Wang

(In reply to Yu Wang from comment #13)
> Test with "all flags", "all but hv_vapic" and "none flag".
> 
> Results are as below:
> 
>                    all         all but hv_vapic      none
> Win2019        5217/5309         5763/6023         4291/4293
> 
> 

What are these numbers, i.e. why do we have two for each test? Is this 
read/write or did you do two runs?

In any case,

 5217/5309 -> 5763/6023

looks like a good result to me (10%/13%) - but I hope I'm actually
comparing apples to apples here.

Comparing with 'none' is also interesting but it doesn't tell you
the impact of any particular feature (I think that hv_time and
hv_stimer have the biggest impact).

(In reply to Vitaly Kuznetsov from comment #14)
> (In reply to Yu Wang from comment #13)
> > Test with "all flags", "all but hv_vapic" and "none flag".
> > 
> > Results are as below:
> > 
> >                    all         all but hv_vapic      none
> > Win2019        5217/5309         5763/6023         4291/4293
> > 
> > 
> 
> What are these numbers, i.e. why do we have two for each test? Is this 
> read/write or did you do two runs?
> 

This means two runs.

> In any case,
> 
>  5217/5309 -> 5763/6023
> 
> looks like a good result to me (10%/13%) - but I hope I'm actually
> comparing apples to apples here.


But, “all but hv_vapic” means that "without hv_vapic".
The performance without hv_vapic is better than with hv_vapic.

> 
> Comparing with 'none' is also interesting but it doesn't tell you
> the impact of any particular feature (I think that hv_time and
> hv_stimer have the biggest impact).

Thanks
Yu Wang

(In reply to Yu Wang from comment #15)
> 
> But, “all but hv_vapic” means that "without hv_vapic".
> The performance without hv_vapic is better than with hv_vapic.
> 

This is very wrong. Let's try doing the test again to double check,
please make sure:
1) Power profile on the host is set to 'performance'
2) HyperThreading is disabled
3) There is nothing else running, just one QEMU
4) In case the host has NUMA pin the guest to CPUs from ONE numa node, 
e.g. 
  the servers has Node0: CPUs0-7, Node1: CPUs8-15
 you set the number of vCPUs to 8 and ping them to CPUs 0-7
 (better 1:1)
5) Make sure Windows guest has enough RAM (>8G) so no swapping is ongoing
6) Run Windows. Make sure there's nothing going on other than your test,
 e.g. that it is not trying to update itself/do some other background work
 (run task monitor and see CPU load inside the guest, it should be close to
  zero) - this needs to be monitored every time you run your test. Just
  disabling Windows Update is not enough, there are multiple other things
  Windows can be busy with.
7) Do the test

In case you're getting constant results where hv_vapic makes the result 
worse I'll need access to the host to investigate.

I tried with the latest method, it increased the performance with hv_vapic.

Results are as below (test 2 runs):

                   all         all but hv_vapic 
Win2019        2998/2863         2211/2463      
Win2016        2257/2447         1967/1629

It have more than 20% improvement.

Test with fast train, the result is almost 10% improvment
refer to : https://bugzilla.redhat.com/show_bug.cgi?id=1729077#c19

And, according to https://bugzilla.redhat.com/show_bug.cgi?id=1729077#c10
in case you need a number for test automation I'd say let's set it fairly low
(e.g. 5%), so , I will use 5% improvement as our testing standard.


Please confirm the steps for our test, correct me if it's not right.
Steps:

1) Create a new raw volume on the host on tmpfs
# qemu-img create -f raw /tmp/disk.raw 5G 

2) Start Windows guest(WS2019), ide/raw

    -smp 6,maxcpus=6,cores=3,threads=1,sockets=2  \
    -cpu 'Broadwell',hv_stimer,hv_synic,hv_vpindex,hv_relaxed,hv_spinlocks=0x1fff,hv_time,hv_frequencies,hv_runtime,hv_vapic,+kvm_pv_unhalt \
    -drive file=/home/kvm_autotest_root/images/win2019-64-virtio-scsi.qcow2,format=qcow2,if=none,id=drive-ide0-0-0 -device ide-hd,bus=ide.0,unit=0,drive=drive-ide0-0-0,id=ide0-0-0,bootindex=1 \
    -drive file=/mnt/tmpfs/data.raw,format=raw,if=none,id=drive-ide1-0-0 -device ide-hd,bus=ide.1,unit=0,drive=drive-ide1-0-0,id=ide1-0-0,bootindex=2 \

3) Partition hard drive, create an NTFS partition

4) Install FIO (https://bsdio.com/fio/)

5) Create fio job, I used the following(numjobs=1,iodepth=1)

[global]
name=fio-rand-RW
filename=fio-rand-RW
directory=D\:\
rw=randwrite
bs=512B
direct=1
numjobs=1
time_based=1
runtime=300

[file1]
size=1G
iodepth=1

6) Let it calm down and run the job, 'fio job.fio'

7) Reboot the guest without 'hv_vapic', let it calm down and run the same job

8) compare the result(more than 5% improvement)

Hi Vitaly,

Could you help to check comment#19?
If the steps and result you accept, I will verify this bug.


Thanks a lot
Yu Wang

Steps look good. I would add one tiny thing to step 3:
disable write caching on the hard drive in Windows 
(device manager -> Disk drives -> Pick the second QEMU HARDDISK -> Policies)
just in case. Maybe this is not really needed for FIO but hard to say
without trying different Windows versions. I'd just disable it.

Got it, I will add it to test plan. Thanks a lot

According to comment#19 and comment#21, change this bug to verified.

Thanks
Yu Wang