chromium-dev

[Chromium-dev] It's the calls to FD_ZERO sucking performance

[Mike H. <mho...@gr...>]

According to the code annotations, thanks again Alan!, the calls to 
FD_ZERO in the recv functions for both SDP and TCP are quite expensive.  
What's odd is that it's the appfaker side that is getting creamed by the 
FD_ZERO in recv.  What the heck is the appfaker doing recv's for?!

-Mike

Re: [Chromium-dev] It's the calls to FD_ZERO sucking performance

[Mike H. <mho...@gr...>]

It's packspu_context that calls crNetRecv()...  Apparently, we call 
packspu_CreateContext repeatedly and do:

while(writeback)
   crNetRecv();

Here is where time is getting sucked away.  I fear that we probably do 
something similar in the tilesort spu...

-Mike

Mike Houston wrote:

> According to the code annotations, thanks again Alan!, the calls to 
> FD_ZERO in the recv functions for both SDP and TCP are quite 
> expensive.  What's odd is that it's the appfaker side that is getting 
> creamed by the FD_ZERO in recv.  What the heck is the appfaker doing 
> recv's for?!
>
> -Mike
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference
> Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer
> Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA
> REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKND
> _______________________________________________
> Chromium-dev mailing list
> Chr...@li...
> https://lists.sourceforge.net/lists/listinfo/chromium-dev

Re: [Chromium-dev] It's the calls to FD_ZERO sucking performance

[Mike H. <mho...@gr...>]

SDP layer choked.  FD_ZERO is not the problem....  grumble.  The 
appfaker does like to do recvs which is still concerning to me.

-Mike

Mike Houston wrote:

> It's packspu_context that calls crNetRecv()...  Apparently, we call 
> packspu_CreateContext repeatedly and do:
>
> while(writeback)
>   crNetRecv();
>
> Here is where time is getting sucked away.  I fear that we probably do 
> something similar in the tilesort spu...
>
> -Mike
>
> Mike Houston wrote:
>
>> According to the code annotations, thanks again Alan!, the calls to 
>> FD_ZERO in the recv functions for both SDP and TCP are quite 
>> expensive.  What's odd is that it's the appfaker side that is getting 
>> creamed by the FD_ZERO in recv.  What the heck is the appfaker doing 
>> recv's for?!
>>
>> -Mike
>>
>>
>> -------------------------------------------------------
>> This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference
>> Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer
>> Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA
>> REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKND
>> _______________________________________________
>> Chromium-dev mailing list
>> Chr...@li...
>> https://lists.sourceforge.net/lists/listinfo/chromium-dev
>
>
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference
> Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer
> Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA
> REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKND
> _______________________________________________
> Chromium-dev mailing list
> Chr...@li...
> https://lists.sourceforge.net/lists/listinfo/chromium-dev

Re: [Chromium-dev] It's the calls to FD_ZERO sucking performance

[Martins D I. <mi...@en...>]

Mike,
	I found the same thing when I was profiling tilesort last week.
Seems to be doing Recv due to Sync on Swap. I guess the FD_ZERO just takes
the most time in that loop.  The problem I found with oprofile was that I
could not get it to tell me how many times a function was called, only how
much time was spent in a function.  I was able to get gmon.out and bb.out
on the crserver side by compiling with "-pg -a" but never got a gmon.out
with any chromium calls in it on the app side (only function calls from my
application), even when doing the symlink trick and not using crappfaker.
bb.out has some decent information in it but some of the files I get are
corrupted so I don't know how much they can be trusted.

Oh, also the "make profile" target is slightly broken( at least in the cr
version I was using).  In cr.mk PROFILE_LAGS should be PROFILE_FLAGS and
in Linux.mk PROFILEFLAGS should be PROFILE_FLAGS.

Let me know if you come up with any profiling tricks.

Martins

On Wed, 16 Jun 2004, Mike Houston wrote:

> It's packspu_context that calls crNetRecv()...  Apparently, we call 
> packspu_CreateContext repeatedly and do:
> 
> while(writeback)
>    crNetRecv();
> 
> Here is where time is getting sucked away.  I fear that we probably do 
> something similar in the tilesort spu...
> 
> -Mike
> 
> Mike Houston wrote:
> 
> > According to the code annotations, thanks again Alan!, the calls to 
> > FD_ZERO in the recv functions for both SDP and TCP are quite 
> > expensive.  What's odd is that it's the appfaker side that is getting 
> > creamed by the FD_ZERO in recv.  What the heck is the appfaker doing 
> > recv's for?!
> >
> > -Mike
> >
> >
> > -------------------------------------------------------
> > This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference
> > Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer
> > Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA
> > REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKND
> > _______________________________________________
> > Chromium-dev mailing list
> > Chr...@li...
> > https://lists.sourceforge.net/lists/listinfo/chromium-dev
> 
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference
> Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer
> Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA
> REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKND
> _______________________________________________
> Chromium-dev mailing list
> Chr...@li...
> https://lists.sourceforge.net/lists/listinfo/chromium-dev
> 

-----------------------------------------------------------------------
Martins Innus				(716) 645-6500 x534
Scientific Visualization Specialist	mi...@cc...
Center for Computational Research	www.ccr.buffalo.edu/martins.htm
University at Buffalo

Re: [Chromium-dev] It's the calls to FD_ZERO sucking performance

[Alan M. <al...@re...>]

On Thu, 2004-06-17 at 08:57, Martins D Innus wrote:
> Mike,
> 	I found the same thing when I was profiling tilesort last week.
> Seems to be doing Recv due to Sync on Swap. I guess the FD_ZERO just takes
> the most time in that loop.  The problem I found with oprofile was that I
> could not get it to tell me how many times a function was called, only how
> much time was spent in a function.  I was able to get gmon.out and bb.out
> on the crserver side by compiling with "-pg -a" but never got a gmon.out
> with any chromium calls in it on the app side (only function calls from my
> application), even when doing the symlink trick and not using crappfaker.
> bb.out has some decent information in it but some of the files I get are
> corrupted so I don't know how much they can be trusted.
> 
If you are running with a 2.6 kernel with oprofile enabled you can run
opstack to get gprof like output.
see http://oprofile.sourceforge.net/doc/opstack.html

You have to apply a kernel patch to make it work though.The web page I'm
referring to has a link to it.


> Oh, also the "make profile" target is slightly broken( at least in the cr
> version I was using).  In cr.mk PROFILE_LAGS should be PROFILE_FLAGS and
> in Linux.mk PROFILEFLAGS should be PROFILE_FLAGS.
> 
> Let me know if you come up with any profiling tricks.
> 
> Martins
> 
> On Wed, 16 Jun 2004, Mike Houston wrote:
> 
> > It's packspu_context that calls crNetRecv()...  Apparently, we call 
> > packspu_CreateContext repeatedly and do:
> > 
> > while(writeback)
> >    crNetRecv();
> > 
> > Here is where time is getting sucked away.  I fear that we probably do 
> > something similar in the tilesort spu...
> > 
> > -Mike
> > 
> > Mike Houston wrote:
> > 
> > > According to the code annotations, thanks again Alan!, the calls to 
> > > FD_ZERO in the recv functions for both SDP and TCP are quite 
> > > expensive.  What's odd is that it's the appfaker side that is getting 
> > > creamed by the FD_ZERO in recv.  What the heck is the appfaker doing 
> > > recv's for?!
> > >
> > > -Mike
> > >
> > >
> > > -------------------------------------------------------
> > > This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference
> > > Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer
> > > Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA
> > > REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKND
> > > _______________________________________________
> > > Chromium-dev mailing list
> > > Chr...@li...
> > > https://lists.sourceforge.net/lists/listinfo/chromium-dev
> > 
> > 
> > 
> > 
> > -------------------------------------------------------
> > This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference
> > Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer
> > Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA
> > REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKND
> > _______________________________________________
> > Chromium-dev mailing list
> > Chr...@li...
> > https://lists.sourceforge.net/lists/listinfo/chromium-dev
> > 
> 
> -----------------------------------------------------------------------
> Martins Innus				(716) 645-6500 x534
> Scientific Visualization Specialist	mi...@cc...
> Center for Computational Research	www.ccr.buffalo.edu/martins.htm
> University at Buffalo
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference
> Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer
> Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA
> REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKND
> _______________________________________________
> Chromium-dev mailing list
> Chr...@li...
> https://lists.sourceforge.net/lists/listinfo/chromium-dev
-- 
Alan Matsuoka
Global Professional Services
Red Hat Canada, Ltd
mailto:al...@re...

Re: [Chromium-dev] It's the calls to FD_ZERO sucking performance

[Martins D I. <mi...@en...>]

> > 
> If you are running with a 2.6 kernel with oprofile enabled you can run
> opstack to get gprof like output.
> see http://oprofile.sourceforge.net/doc/opstack.html
> 
> You have to apply a kernel patch to make it work though.The web page I'm
> referring to has a link to it.

Yeah, we're still running a 2.4 kernel and I don't see an upgrade in
the near future. Thanks.

Martins

Re: [Chromium-dev] It's the calls to FD_ZERO sucking performance

[Brian P. <bri...@tu...>]

Mike Houston wrote:
> It's packspu_context that calls crNetRecv()...  Apparently, we call 
> packspu_CreateContext repeatedly and do:
> 
> while(writeback)
>   crNetRecv();
> 
> Here is where time is getting sucked away.  I fear that we probably do 
> something similar in the tilesort spu...

packspu_CreateContext() is called only when a new rendering context is 
created.  I don't see it being repeatedly called.

-Brian

Re: [Chromium-dev] It's the calls to FD_ZERO sucking performance

[Mike H. <mho...@gr...>]

SDP layer choked.  FD_ZERO is not the problem....  grumble.  The 
appfaker does like to do recvs which is still concerning to me.

-Mike

Mike Houston wrote:

> According to the code annotations, thanks again Alan!, the calls to 
> FD_ZERO in the recv functions for both SDP and TCP are quite 
> expensive.  What's odd is that it's the appfaker side that is getting 
> creamed by the FD_ZERO in recv.  What the heck is the appfaker doing 
> recv's for?!
>
> -Mike
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference
> Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer
> Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA
> REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKND
> _______________________________________________
> Chromium-dev mailing list
> Chr...@li...
> https://lists.sourceforge.net/lists/listinfo/chromium-dev