[mythtv-users] Mythfrontend idle cpu consumption help

[Jim Stichnoth]

On Sun, Nov 15, 2009 at 8:51 PM, Michael T. Dean
<mtdean at thirdcontact.com> wrote:
> On 11/15/2009 06:46 PM, Mark Garland wrote:
>> This thread is a little confusing as there seems to be two or more off-topic
>> conversations going on at once so I'm not quite sure what's relevant.  I'm
>> pretty sure fiddling with deinterlacers wont help this issue, but I'll
>> certainly try setting timezones if people think this is related and tell me
>> how.
>>
>
> Setting time zone will /not/ have any effect at all--other than possibly
> preventing you from starting parts of Myth.  The fact that the time zone
> check was being done /just before/ the UI event thread starting tying up
> the CPU is unrelated to the issue.  Someone in the thread just saw time
> zone before a bunch of checks reading the clock (in the Qt event thread)
> and thought it might be related.  It's not.

I'm the one who brought this up.  To recap:
1. Unless I set TZ, Qt (or something initiated by Qt) is stat'ing
/etc/localtime at about 70 times per second.
2. 70 times per second is due to the MythUIType::Pulse() code.
3. /etc/localtime is on NFS on my diskless system.
4. The 2.6.27 kernel (which Fedora 10 uses) has an NFS bug related to
caching credentials that can make NFS accesses CPU-intensive.

All this put together leads to the system consuming more and more CPU
over time and getting more and more sluggish, as the NFS credential
cache gets bogged down.  It's a pretty narrow set of circumstances and
is surely separate from the other kinds of behaviors being reported.

By the way, I noticed increased sluggishness over time even with TZ
set.  I found that it's again this NFS problem.  When you change
screens (e.g., going from the main menu to the Watch Recordings page),
the MythUI code rechecks all the theme graphics files for the new page
to see if the cached versions are still valid.  For the Blue Abstract
theme I'm using, there were actually about 2000 such checks across 113
distinct files to enter the Watch Recordings screen, with several
files being checked 100 or 200 times each.  (I suppose that even if my
NFS were working properly, one could make a case for optimizing away
thousands of system calls.)

>
> Again, I /seriously/ believe that if there's an issue, it's in Qt (and I
> saw no obvious errors in the code that was being executed) or the
> underlying libc.
>
> I would be /very/ interested to know if anyone using a non-Debian-based
> system (i.e. someone other than Debian and Ubuntu users) is seeing the
> issue.  Debian just swapped out libc's, and I'm pretty sure that
> current/new Ubuntu is using eglibc (the different libc).

For the record, I'm running Fedora 10, without eglibc.  However, I
don't think I'm experiencing the same problem as others are reporting.

Jim