Re: runaway intr problems: powerd and/or hw.acpi.cpu.cx_lowest related

> Date: Mon, 23 Aug 2010 11:56:17 -0700
> From: Doug Barton <dougb_at_FreeBSD.org>
> Sender: owner-freebsd-current_at_freebsd.org
> 
> On 08/23/2010 05:39, John Baldwin wrote:
> > On Sunday, August 22, 2010 11:17:44 pm Doug Barton wrote:
> >> Thanks to help from Andriy I've been working on narrowing down the cause
> >> of my "runaway intr" problems and we've found some interesting things.
> >> First, if I use neither powerd nor set hw.acpi.cpu.cx_lowest less than
> >> C1 things seem to work fine. Using one or the other sort of works, but
> >> between the 2 powerd seems to cause the most problems.
> >
> > I think this just means that when C3 is enabled the system is getting skewed
> > results in cp_time[] and so the stats are off.  The system isn't actually
> > stuck in an interrupt storm of sorts, the numbers reported to top are just
> > wrong so it looks like it is.
> 
> That may be true, however what's happening at that time is that the 
> video and audio both become choppy (as in, painfully so) and every other 
> thing that's running, whether it's desktop clients like thunderbird or 
> something being compiled, also moves very very slow, as if it's 
> resource-starved. So while I'm perfectly ready to admit that the top 
> output may be just a symptom instead of the real problem, something 
> fundamentally bad IS happening under the hood.

This sounds wrong. C3 should only be entered when a CPU is halted for an
extended time. When I am plying a movie, I never see C3, but I am using
an old uniprocessor on my T43.

I would believe that dropping to C3 could be detrimental to playing
video as it takes quite a few clock cycles for the system to climb out
of C3 and start doing real work again.

Things that come to mind...does the player move between CPUs while this
is going on? Does ULE take processor ACPI state into account when
scheduling? Can you try locking the player to a single CPU with
cpuset(1) so it does not move around? Try different CPUs. Some are
more equal than others, at least in my network performance testing using
FreeBSD and I have been unable to figure out, other than empirically,
which ons(s) work best.

just some random thoughts from an un-air conditioned office on a very
hot afternoon in Berzerkley. I may simply be delirious. :-)
-- 
R. Kevin Oberman, Network Engineer
Energy Sciences Network (ESnet)
Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab)
E-mail: oberman_at_es.net			Phone: +1 510 486-8634
Key fingerprint:059B 2DDF 031C 9BA3 14A4  EADA 927D EBB3 987B 3751