[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <1272655814.3879.8.camel@bigi>
Date: Fri, 30 Apr 2010 15:30:14 -0400
From: jamal <hadi@...erus.ca>
To: Eric Dumazet <eric.dumazet@...il.com>
Cc: Changli Gao <xiaosuo@...il.com>,
David Miller <davem@...emloft.net>, therbert@...gle.com,
shemminger@...tta.com, netdev@...r.kernel.org,
Eilon Greenstein <eilong@...adcom.com>,
Brian Bloniarz <bmb@...enacr.com>
Subject: Re: [PATCH net-next-2.6] net: speedup udp receive path
Eric!
I managed to mod your program to look conceptually similar to mine
and i reproduced the results with same test kernel from yesterday.
So it is likely the issue is in using epoll vs not using any async as
in your case.
Results attached as well as modified program.
Note: the key things to remember:
rps with this program gets worse over time and different net-next
kernels since Apr14 (look at graph i supplied). Sorry, I am really
busy-ed out to dig any further.
cheers,
jamal
On Thu, 2010-04-29 at 16:36 -0400, jamal wrote:
> On Thu, 2010-04-29 at 09:56 -0400, jamal wrote:
>
> >
> > I will try your program instead so we can reduce the variables
>
> Results attached.
> With your app rps does a hell lot better and non-rps worse ;->
> With my proggie, non-rps does much better than yours and rps does
> a lot worse for same setup. I see the scheduler kicking quiet a bit in
> non-rps for you...
>
> The main difference between us as i see it is:
> a) i use epoll - actually linked to libevent (1.0.something)
> b) I fork processes and you use pthreads.
>
> I dont have time to chase it today, but 1) I am either going to change
> yours to use libevent or make mine get rid of it then 2) move towards
> pthreads or have yours fork..
> then observe if that makes any difference..
>
>
> cheers,
> jamal
View attachment "apr30-ericmod" of type "text/plain" (8919 bytes)
View attachment "udpsnkfrk.c" of type "text/x-csrc" (3651 bytes)
Powered by blists - more mailing lists