[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] xen_evtchn_do_upcall

On Wed, 2012-10-24 at 14:39 +0100, David Xu wrote:
> Hi Lan,
> Thanks for your reply. I did a experiment as follows, 
> I assigned 2 vCPU to a VM, one vCPU (vCPU0) was pinned to a physical
> CPU shared with several other VMs and the other vCPU (vCPU1) was
> pinned to an idle physical CPU occupied by this VM only. Then in Guest
> OS I run iperf server to measure its TCP receiving throughput. In
> order to shrink the receiving delay caused by vCPU scheduling, I pin
> the IRQ context of NIC to vCPU1 and run iperf server on the vCPU0.
> This method works well for UDP, but does not work for TCP. I track the
> involved function by ftrace and get the following results which
> contains lots of xen_evtchn_do_upcall routine. What's the meaning of
> this process (xen_evtchn_do_upcall => handle_irq_event =>
> xennet_tx_buf_gc =>  gnttab_query_foreign_access)?

Have you looked at the code for any of those functions?

If you had done you'd find it is pretty obviously an interrupt being
delivered to the network device and the associated work to satisfy that

It doesn't seem that surprising that an iperf test should involve lots
of network interrupts.

It's not entirely clear to me what you are expecting to find and/or what
you are trying to prove.

> When I run both process context of application ( e.g. iperf server )
> and IRQ context on vCPU1 which is the ''fast" core, no
> any xen_evtchn_do_upcall routine found. 

Perhaps on the fast core NAPI is able to kick in and therefore the NIC
becomes polled instead of interrupt driven?


Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.