[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 21:22:11 +0200
    > From: Daniel Staaf <dst at bostream.nu>

    > f-myth-users at media.mit.edu wrote:
    > > 
    > > 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.

    > Yes, no need to recompile.

Well, I tried "echo cfq > /sys/block/hdX/queue/scheduler", for X=a or c
on both of my machines.  It doesn't appear to have made -any- difference;
even though "cat /sys/block/hd*/queue/scheduler" now reported that all
4 disks were using CFQ, my stress-test still provoked exactly the same
glitches when the scheduler ran, e.g., if I'm recording on multiple
streams and running several commflaggers, the end-of-recording run of
the scheduler causes all streams being recorded to glitch, and logs
several IOBOUND errors in the backend log.  [Presumably, this also
means that even -one- stream and -no- commflaggers would glitch upon
scheduler run if I was also copying a large file between hda and hdc,
as I noted in my previous message.]

(At this point, I don't know if it's becauze Breezy's 2.6.12 kernel is
ignoring the setting and using AS scheduling anyway, or if there's
something else going on.  I might try booting with "elevator=cfq"
just in case setting it at boot works but setting it on the fly
doesn't in 2.6.12, but that requires testing when I can do a reboot.)

    > You may also want to play with "ionice" from the schedutils package (the
    > one in Breezy (universe) is to old so you have to compile your own, the
    > source is at http://rlove.org/schedutils/schedutils-1.5.0.tar.gz).

Does ionice even -work- in a 2.6.12 kernel, or do I need 2.6.13 or later?
(At some point, I"ll probably try out Dapper, which has a newer kernel, 
and either 0.18.1 there as a base case [to test CFQ and ionice] or 0.20
directly in the hope that 20's scheduler query hits mysql less hard.
But until then, it'd be nice if I could figure out if Breezy/0.18.1
can be made to work.)

    > > [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...]

    > CFQ will be the default for 2.6.18 and later upstream kernels.

It'll be a -long- time before I'm running 2.6.18, since even Dapper
doesn't run it, and I'd like to stay with out-of-the-box kernels
unless it's my only alternative.