Custom apps task priority.

R

raydon

Well-Known Member
I've still been experiencing some degree of screen corruption on my T2 when recording one channel and viewing a second. It only seems to happen in the first five minutes or so after bootup, then it settles down. I was wondering if it might be the epg database being processed so I had a look at the task list. I was surprised to find that the custom apps were all being started with a lower nice value (higher priority bias) than humaxtv.:eek: (See the NI (nice) column in the edited list attached below.
@af123: Any idea where the tasks are inheriting the -5 nice value from, and could this be the cause of my problems ?

Code: 
HDRFOXT2# ps axl
F  UID  PID  PPID PRI  NI    VSZ  RSS WCHAN  STAT TTY        TIME COMMAND
4    0  173  152  17  0  97884 36140 hrtime Sl  ?          0:35 /usr/bin/humaxtv
1    0  328    1  19  0  1516  240 select Ss  ?          0:00 udhcpc -t 5 -T 10 -p /var/lib/humaxtv/udhcpc.eth0.pid -i eth0
1    0  639    1  16  -5  1356  352 hrtime S<s  ?          0:00 /mod/sbin/crond
0    0  640    1  10  -5  12380  656 hrtime S<l  ?          0:00 /mod/sbin/mongoose /mod/etc/mongoose.conf
0    0  724    1  20  -5  3676  3020 hrtime S<  ?          0:21 /mod/bin/epg -f /mnt/hd1/dvbepg/epg.dat sqlitedumpd /mnt/hd1/epg.db
1    0  746    1  16  -5    924  156 sys_po S<  ?          0:00 /mod/sbin/betaftpd
0    0  821  132  18  0  1264  448 wait  Ss  pts/0      0:00 /bin/sh /bin/tmenu
0    0  857  821  15  0  1236  428 wait  S    pts/0      0:00 /bin/sh -l
0    0  868  857  17  0  1260  448 -      R+  pts/0      0:00 ps axl
HDRFOXT2#
 
I don't know where the -5 is coming from. Most of the intensive tasks (like auto) are deliberately run as 19. Looks like the rcS script should do something similar.

I don't know if it's the cause of your problems though.
 
af123 said:
I don't know where the -5 is coming from. Most of the intensive tasks (like auto) are deliberately run as 19. Looks like the rcS script should do something similar.

I don't know if it's the cause of your problems though.
Click to expand...
O.K. thanks. I've edited my rcS script as below to give them a nice value of 10. Will just have to monitor things and see if this resolves the issue.
Code: 
#!/bin/sh
# Start all init scripts in /etc/init.d
# executing them in numerical order.
#
 
 
# Source defaults.
. /etc/default/rcS
export VERBOSE
 
# Trap CTRL-C &c only int this shell so we can interrupt subprocesses.
trap ":" INT QUIT TSTP
 
steps=$(echo /mod/etc/init.d/S??*)
 
for i in $steps
do
    # Ignore dangling symlinks (if any).
    [ ! -f "$i" ] && continue
 
    case "$i" in
    *.sh)
        # Source shell script for speed.
        (
        trap - INT QUIT TSTP
        set start
        . nice -15 $i
        )
        ;;
    *)
        # No sh extension, so fork subprocess.
        nice -15 $i start
        ;;
    esac
done
 
That's interesting. I occasionally get picture break-ups in the first five to ten minutes of recordings.
I had wondered if something was choking the cpu and causing the recording to be messed up.

BTW I can't see 10 anywhere in the above script.
 
jxp said:
BTW I can't see 10 anywhere in the above script.
Click to expand...
No, you won't. The nice value being set for processes running under the CFW is -5, (System default is 0). Any nice value you define when starting a child process will be added to that.
So -5 + 15 = 10. (the nice value -15 you see in the script is actually a positive value. You can also write it as nice -n 15 which reads a bit better). If you want to set a negative value you would use nice --14, or nice -n -14, which would give you -19, the highest priority you can set.
 
I just tried to run
Code: 
ps axl
in the cli (via telnet) but it said invalid option -- a

Is there another package I need to install?
 
The procps package includes a more complete implementation of the ps command. raydon probably has that installed.
 
  • Like
Reactions: jxp
Thanks that did it. Mine also showed several processes on -5

Code: 
1    0  567    1  16  -5  1368  380 hrtime S<s  ?          0:00 /mod/sbin/crond
0    0  569    1  10  -5  12408  1052 hrtime S<l  ?          0:00 /mod/sbin/mongoose /mod/etc/mongoose.conf
0    0  588    1  10  -5  3772  3116 hrtime S<  ?          0:51 /mod/bin/epg -f /mnt/hd1/dvbepg/epg.dat sqlitedumpd /mnt/hd1/epg.db
0    0  621    1  10  -5  1052  448 select S<l  ?          0:00 /mod/sbin/auto-unprotectd -d /mnt/hd2/dms_cds.db /media/My Video/
 
Mine too. Just committed a patch to the next version of the CFW that will change that, thanks Raydon.

Code: 
Index: sbin/modinit
===================================================================
--- sbin/modinit    (revision 1695)
+++ sbin/modinit    (working copy)
@@ -98,11 +98,16 @@
     # Previous versions of the firmware left the PATH= line in the new rcS
     #  - delete the file if that's the case so it is recreated.
     [ -x $newrcS ] && grep -q PATH= $newrcS && rm -f $newrcS
+    # Previous versions of the firmware did not use renice.
+    #  - delete the file if that's the case so it is recreated.
+    [ -x $newrcS ] && grep -q renice $newrcS || rm -f $newrcS
     if [ ! -x $newrcS ]; then
         echo "+ Creating $newrcS"
         cat /etc/init.d/rcS | sed "
             s^/etc/init.d/^$mdir&^
             /PATH=/d
+            /steps=/a\\
+renice 10 \$\$
             " > $newrcS
         chmod 755 $newrcS
     fi
 
xyz321 said:
Does auto-unprotect still work? The timing of that is quite critical.
Click to expand...
I don't think it's that critical that a few microseconds will make much difference. It's only waiting for a recording to end before writing the unprotected flag into the .hmt file.
Edit: Just tried it with a short HD recording and it works fine using a nice value of 10.:)
 
Ezra Pound said:
Would it be possible to post the modified /sbin/modinit so that it can be tried out prior to the release of the new CFW?
Click to expand...
Sorry Ezra, the file resides in firmware so you can't test the modified /sbin/modinit. What you can do is test the revised /mod/etc/init.d/rcS file it will create. Basically, the revised rcS script is just renicing itself, so that all the child processes it spawns inherit the new nice value. Just use the file editor from the diagnotics screen and edit /mod/etc/init.d/rcS by adding the line renice 10 $$ where you see it in the example below.

Code: 
#!/bin/sh
# Start all init scripts in /etc/init.d
# executing them in numerical order.
#
 
 
# Source defaults.
. /etc/default/rcS
export VERBOSE
 
# Trap CTRL-C &c only int this shell so we can interrupt subprocesses.
trap ":" INT QUIT TSTP
 
steps=$(echo /mod/etc/init.d/S??*)
renice 10 $$
 
for i in $steps
do
    # Ignore dangling symlinks (if any).
    [ ! -f "$i" ] && continue
 
    case "$i" in
    *.sh)
        # Source shell script for speed.
        (
        trap - INT QUIT TSTP
        set start
        . $i
        )
        ;;
    *)
        # No sh extension, so fork subprocess.
        $i start
        ;;
    esac
done
 
Note that renice doesn't exist in the CFW 2.16 root (although it will in 2.17) so for testing you need:

Code: 
/mod/bin/busybox/renice 10 $$
 
af123 said:
Note that renice doesn't exist in the CFW 2.16 root (although it will in 2.17) so for testing you need:

Code: 
/mod/bin/busybox/renice 10 $$
Click to expand...
Isn't this already handled by modinit calling /mod/.env to export a path to /mod/bin/busybox before calling /mod/etc/init.d/rcS ? Or is this to cater for new installs of CFW where the busybox package has not been installed yet ?
 
Used the /mod/bin/busybox/renice 10 $$ version, although renice without the busybox path seems to work from all the sub directories I have tried. the custom packages shown in #8 are now showing a 'nice' of 10, there are still some nice -5 but they appear to be non custom firmware processes. We'll have to see how it goes
Code: 
1    0  1028    1  25  10  1368  380 hrtime SNs  ?          0:00 /mod/sbin/crond
0    0  1030    1  25  10  12408  932 hrtime SNl  ?          0:00 /mod/sbin/mongoose /mod/etc/mongoose.conf
0    0  1112    1  25  10  1028  416 select SN  ?          0:00 /mod/sbin/recmon /mod/sbin/rslog
0    0  1134    1  35  10  4136  3480 hrtime SN  ?          0:39 /mod/bin/epg -f /mnt/hd1/dvbepg/epg.dat sqlitedumpd /mnt/hd1/epg.db
1    0  1182    1  27  10    924  156 sys_po SN  ?          0:00 /mod/sbin/betaftpd
0    0  1268    1  28  10  1052  436 select SNl  ?          0:00 /mod/sbin/auto-unprotectd -d /mnt/hd2/dms_cds.db /media/My Video/
 
raydon said:
Isn't this already handled by modinit calling /mod/.env to export a path to /mod/bin/busybox before calling /mod/etc/init.d/rcS ? Or is this to cater for new installs of CFW where the busybox package has not been installed yet ?
Click to expand...

You're right - I forgot that the rc scripts are called from modinit so in most cases it will work (almost everyone has webif + supporting packages installed).

I've done some digging and the priority is being inherited from keventd because the whole modinit process is triggered by a kernel hotplug event calling mdev.

It is something that was fixed in Linux kernel 2.6.22 (see https://github.com/torvalds/linux/commit/b73a7e76c1eeaa770a41554698917c3c45686a07) but the Humax runs 2.6.18

Nice catch. I will update the CFW to fix this and also deploy an interim patch as part of a webif update.
 
You must log in or register to reply here.
Back
Top