On Jul 2, 2020, at 3:36 PM, Ying Fang <fangying1@huawei.com> wrote:
On 7/2/2020 3:18 PM, Haibin Zhang wrote:
Hi, Ying Fang.Hi Haibin, Thanks for report this issue for us.
We will verify and response to you later.
I use qemu create a VM (96 cores and 360g ram) on my kunpeng 920-4826 server, then do unixbench tests.Could you provide more details about your OS and virtualization software version information for us?
The performance of pipe-based context switching decreases severely, which shows below:
Guest# ./context1 60
COUNT|4779535|1|lps
COUNT|4779536|1|lps
Host# ./context1 60
COUNT|13990745|1|lps
COUNT|13990746|1|lps
As you know, pipe-based context switching measures the number of times two processes can exchange an
increasing integer through a pipe in a duration (like 60 seconds). Times of guest is only 34% as that
of host. Attachment is the context1.c from unixbench. It looks simple, just spawn a child process with
which it carries on a bi-directional pipe conversation.
Yes, we had knowledge about this context test now. Thanks.
Guest# taskset -c 20 ./context1 60
COUNT|18059443|1|lps
COUNT|18059443|1|lps
Host# taskset -c 20 ./context1 60
COUNT|17881974|1|lps
COUNT|17881975|1|lps
Use taskset to set cpu affinity, which makes results better.
Can you help me fix this issue? Maybe WFE/WFI traps lead the performance cost? Is there PLE(Pause Loop Exit) feature on Kunpeng?
We had some performance tuning techniques in the openEuler OS.
And Xie XiangYou is the expert on this area, maybe he could help you with it.