From mboxrd@z Thu Jan 1 00:00:00 1970 From: Iurii Konovalenko Subject: Question about high CPU load during iperf ethernet testing Date: Mon, 22 Sep 2014 16:01:15 +0300 Message-ID: Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3517651629071694402==" Return-path: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: xen-devel@lists.xen.org Cc: Julien Grall , Ian Campbell , Stefano Stabellini List-Id: xen-devel@lists.xenproject.org --===============3517651629071694402== Content-Type: multipart/alternative; boundary=047d7b674278c8f8a90503a70b78 --047d7b674278c8f8a90503a70b78 Content-Type: text/plain; charset=UTF-8 Hello, all! I am running iperf ethernet tests on DRA7XX_EVM board (OMAP5). Xen version is 4.4. I run only Linux (kernel 3.8) as Dom0, no other active domains (For clear tests results I decided not to start DomU). iperf server is started on host, iperf client is started on board with command line "*iperf -c 192.168.2.10 -w 256k -m -f M -d -t 60*". During test I studied CPU load with top tool on Dom0, and saw, that one VCPU is totally loaded, spending about 50% in software IRQs, and 50% in system. Running the same test on clear Linux without Xen, I saw that CPU load is about 2-4%. I decided to debug a bit, so I used "*({register uint64_t _r; asm volatile("mrrc " "p15, 0, %0, %H0, c14" ";" : "=r" (_r)); _r; })*" command to read timer counter before and after operations I want to test. In such way I've found, that most time of CPU is spent in functions *enable_irq/disable_irq_nosync* and *spin_lock_irqsave/spin_unlock_irqrestore* (mostly in "*mrs %0, cpsr @ arch_local_irq_save*"/*"msr cpsr_c, %0 @ local_irq_restore"*). When running without Xen it should not take so much time. So, could anyone explain me some questions: 1. Is it normal behaviour? 2. Does hypervisor trap cpsr register? I suppose, that hypervisor trap access to cpsr register, that leads to additional overhead, but I can't find place in sources where it happens. Thank you in advance. Best regards. Iurii Konovalenko | Senior Software Engineer GlobalLogic P +3.8044.492.9695 M +38.099.932.2909 S yufuntik www.globallogic.com http://www.globallogic.com/email_disclaimer.txt --047d7b674278c8f8a90503a70b78 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello, all!

I am running = iperf ethernet tests on DRA7XX_EVM board (OMAP5).
Xen version is 4= .4.
I run only Linux (kernel 3.8) as Dom0, no other active domains= (For clear tests results I decided not to start DomU).
iperf= server is started on host, iperf client is started on board with command l= ine "iperf -c 192.168.2.10 -w 256k -m -f M -d -t 60".
<= br>
During test I studied CPU load with top tool on Dom0, and saw, that one VCPU=20 is totally loaded, spending about 50% in software IRQs, and 50% in=20 system.
Running the same test on clear Linux without Xen, I s= aw that CPU load is about 2-4%.

I decided to debug a bit,= so I used "({register uint64_t _r; asm volatile("mrrc " = "p15, 0, %0, %H0, c14" ";" : "=3Dr" (_r)); _r= ; })" command to read timer counter before and after operations I = want to test.

In such way I've found, that most time = of CPU is spent in functions enable_irq/disable_irq_nosync and sp= in_lock_irqsave/spin_unlock_irqrestore (mostly in "mrs=C2=A0=C2= =A0=C2=A0 %0, cpsr=C2=A0=C2=A0=C2=A0 @ arch_local_irq_save"/&qu= ot;msr=C2=A0=C2=A0=C2=A0 cpsr_c, %0=C2=A0=C2=A0=C2=A0 @ local_irq_restore&q= uot;). When running without Xen it should not take so much time.

So, could anyone explain me some questions:
1. Is it normal behaviour?
2. Does hypervisor trap cpsr register? I suppose, that hypervisor trap=20 access to cpsr register, that leads to additional overhead, but I can't= =20 find place in sources where it happens.

Thank = you in advance.
=
Best regards.

Iurii Konovalenko=C2=A0| Senior Software Engineer=
GlobalLogic
P=C2=A0+3.8044.492.9695 M +3= 8.099.932.2909=C2=A0=C2=A0
S= =C2=A0yufuntik
--047d7b674278c8f8a90503a70b78-- --===============3517651629071694402== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============3517651629071694402==--