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
> Gnash-dev@gnu.org
> http://lists.gnu.org/mailman/listinfo/gnash-dev
>
_______________________________________________
Gnash-dev mailing list
Gnash-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnash-dev
