Re: Fwd: Re: buildworld panics with yesterday's kernel ...

[Andrew Atrens <atrens@xxxxxxxxxxxxxxxxxx>]

803@xxxxxxxxxxxxxxxxxx> <409a6e46$0$50172$415eb37d@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> <200405061745.i46HjQJ7083412@xxxxxxxxxxxxxxxxxxxx>
Organization: Nortel Networks
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7Bit
Lines: 49
NNTP-Posting-Host: 47.128.22.25
X-Trace: 1083871267 crater_reader.dragonflybsd.org 50174 47.128.22.25
Xref: crater_reader.dragonflybsd.org dragonfly.bugs:1130

Matthew Dillon wrote:

> 
> :Well I'm still seeing (seemingly) random GL performance. Sometimes my
> :xscreensaver hacks run fast and use little cpu, other times they run
> :deadly slow and consume all available cpu. If a hack is running fast
> :and I try to drag it's window around the hack and X get very slow and
> :jerky. Once it has settled into place, the hack resumes full speed.
> :
> :Stability is good - no crashes or corruption ...
> :
> :Andrew.
> 
>     I think this may be an alignment issue.  The XMM code only runs if
>     there is 16-byte alignment.  The MMX code, however, will run on
>     unaligned data.  It works, it just isn't fast.
> 
>     I think you answered this already but does this fast/slow issue occur
>     when the FP copy code is turned off?  I don't do an alignment check

Yes it does, but there seems to be subtle changes in the cadence of the
problems. Typically the behaviour I see is:

1. run the screensaver hack
2. wait
3. run the screensaver hack again

If I wait at step 2. for say 10 minutes, when I re-run the hack in step
3. it always works normally.  If I decrease the interval, generally
speaking, the likelihood of the hack running properly diminishes.

Though the data is pretty random, I can say that, generally speaking, with
mmxopt=0 I can run hacks successfully with a much smaller wait interval,
than if I have mmxopt=1 .  That said I haven't done any tests with mmxopt=0
today.

>     in my integer loop either, but it might not matter as much.

The differences between normal 50fps (at 4% cpu) vs slow 1fps (at 99% cpu)
are so striking that I'd be surprised if it was the unaligned data transfer
itself that was causing it.

I'd actually thought it might have to do with locking and GL thread context
getting mucked up somehow.

Andrew.