[mythtv] [mythtv-commits] Ticket #1791: Stop transcode/commflag from hogging the CPU while recording/playback is in progress.

[f-myth-users at media.mit.edu]

    Date: Thu, 14 Sep 2006 09:33:03 +0200
    From: Daniel Staaf <dst at bostream.nu>

    f-myth-users at media.mit.edu skrev:
    > 
    > Any other ideas?

    How about changing the kernel I/O scheduler to CFQ?

    CONFIG_IOSCHED_CFQ=y
    CONFIG_DEFAULT_CFQ=y
    CONFIG_DEFAULT_IOSCHED="cfq"

Now -that- is a fascinating idea.  I take it that the problem here is
the kernel's I/O scheduling policy, more than simply what the IDE
buses can do in theory---which makes sense.  I'm gathering from some
research that this might lower overall throughput a bit at the benefit
to not starving any particular I/O thread out, which would be just
perfect, since I've got plenty of aggregate throughput as long as I
can keep the ivtv threads from totally starving when MySQL runs.

Some more research -seems- to indicate that the Breezy kernel these
machines run might be fixable simply by adding
  elevator=cfq
to the boot line, and adding
  # nonaltoptions=quiet splash elevator=cfq
so it winds up on kernel updates as well.  I'm hoping that this is
true, since I'd rather not have to compile a non-stock kernel (as
your example seems to indicate).

It also appears I can change this on the fly with
  echo cfq > /sys/block/hdX/queue/scheduler
per-disk, and check the current setting for all disks with
  cat /sys/block/hd*/queue/scheduler
so I may be able to screw around with this without even rebooting.

[According to the /sys above, my current Breezy kernels seem to be
using anticipatory (AS) scheduling, which seems like the absolute
worst case for a system handling realtime video!  Yuck.  This is
apparently the Breezy default; it appears that it might be the best
for a system requiring good interactive response but is pitiful for
I/O latency; c.f. www.redhat.com/magazine/008jun05/features/schedulers/
for some comparisons run using RHEL4 and a shocking barchart...]

I'll have to give this a try sometime when I have time to test out the
changes (probably next week at this rate).

Thanks!

(Though if anyone's got any other ideas wrt MySQL itself, for example,
those would be welcome as well, just in case CFQ doesn't do it or it
isn't stable in Breezy's kernel or whatever.)