Open zhilongzheng opened 5 years ago
The number of batched events can vary depending on the the driver at the I/O layer and the size of your workload. The numbers in the paper were measured with PSIO which supports event-driven I/O scheduling. mTCP threads wake up less frequently and batch more events at a time. On the other hand, mTCP with DPDK polls packets from NICs, resulting in more frequent event handling/smaller batch size. However we didn't see much performance degradation when we moved from PSIO to DPDK.
Thank you for your quick reply!
I'll test more types of workloads
Hi,
I am tuning the performance of mTCP aware applications. However, I cannot get a relatively large improvement against Linux kernel based implementation.
The mTCP paper shows that a design to improve performance is
Batched Event Handling
. BUT, I found the returned number of events frommtcp_epoll_wait(mctx, events, -1)
is small, which is stablely distributed and varied from 1 to ~64 (a lot of 1). Even through I stress the workload generator (wrk
was used and variedConcurrency from 1024 to 8192
), it seems no obvious increase on returned value of events.I recorded the number of returned events on mTCP's two example applications (epserver.c & lighttpd-mtcp). Both reported a similiar result.
AND, I checked the flushed epoll events in
FlushEpollEvents()
function, it also printfs a small events number.Only one CPU core was used to observe the above outputs and the default mTCP config file with adjusted core_mask was used.
My question is: Does such a small batch size of events have the potential to degrade end-to-end performance SIGNIFICANTLY?
My testing was conducted on a server with two 12-core CPUs and and Intel X710 NIC as mTCP server and 6 other servers as workload generators.