Re: [Gnash-dev] fix cpu burning before code freeze?

[Andrea Palmatè]

Eheh,
this seems the same problem i have on AmigaOS4 since ages.
There is something that put my cpu at 100% when i play a youtube video for 
example. The video starts at 20% but after 1 minute the cpu reach the 100% and 
something seems to grow..
And maybe on OS4 is more accentuate than linux

Andrea

Il giorno 20/lug/2010, alle ore 22.20, John Gilmore ha scritto:

>> Can anyone think of anything critical that should be fixed before the
>> code freeze ?
> 
> The one thing I've been hoping to get to (but haven't) is whatever
> makes gnash burn up massive CPU time when the flash movie is idling.
> E.g.  in youtube after finishing playing a movie.  Yes, there's little
> stuff going on, moving thumbnails around every few seconds, but we
> shouldn't be burning up a whole CPU to do it.
> 
> If it's something easy, let's fix it; if it's something hard, let's
> at least start to understand it.
> 
> When gnash is in that state, top shows 100% cpu utilization of one core.
> There are 5 threads.  All are running, doing system calls, according to
> strace.  I did "strace -p 6519 -f -ff -o gnash.idle" and got five files
> of syscalls, one per thread.  I interrupted it after about 10.3 seconds
> (measured by the gettimeofday results in the files).
> 
> The lowest numbered thread (6519) is doing endless gettimeofday()
> calls, more than 17,000 in my 10-second sample, plus an occasional
> read(3) getting EAGAIN followed by polling fd's 4 and 3 for input,
> with a ZERO timeout!  (Maybe that timeout should be longer?)
> 
> Thread 6525 is doing nanosleep({0, 100000}, NULL) = 0 continuously.
> Never doing any other system calls.  Why is its sleep so short (100K
> nanoseconds, or 100 microseconds, or 0.1 milliseconds = waking up 10,000
> times/second)?
> 
> Thread 6527 is doing something repetitive; it writes "x" to fd 11,
> polls fd's 12 and 14, gets input on 12, sends a 20-byte binary packet
> on 14, reads a "W" from 12, polls again (awakened by output on 14),
> sends a 16-byte packet on 14, polls again (awakened by output on 14),
> does clock_gettime twice, polls again for input only (awakened by
> input on 14), receives a 20-byte message on 14, repeats this
> poll/receive loop three times, then writes an "x" to fd 11 and starts
> over.  It also did more than 7000 clock_gettime calls and 1700 futex
> calls during my 10-second sample.
> 
> Thread 6528 appears to be the other side of this mysterious
> communication; it's writing "W"s to fd 13 and reading "x"s from fd 10,
> and other than its almost 3000 futex() calls and a poll awaiting input
> on fd 10, it behaves nicely (its poll is with infinite timeout).
> 
> Thread 6529 is sending and receiving HTTP protocol on fd 23, getting
> JPEG files and writing them into files in /tmp, but is also doing
> short-timeout select() and poll() calls (select {0,10000} and poll 0).
> Bizarrely, the select() calls has no file descriptors selected, so it
> always waits; but as soon as the process wakes up from it, it does a
> zero-timeout poll() call on fd 23.  Pushing these two together to
> select() on fd 23 might eliminate the need for short timeouts in both
> calls.  It also did 204 clock_gettime calls in my 10-second sample.
> 
> Perhaps just adjusting the timeouts in our select and poll calls will
> eliminate the useless burning of CPU time.  The other obvious
> performance question is whether we need all the gettimeofday() and
> futex() calls that we're doing.
> 
>       John
> 
> 
> _______________________________________________
> Gnash-dev mailing list
> address@hidden
> http://lists.gnu.org/mailman/listinfo/gnash-dev
>