Is SCHED_FIFO on Woody working?
Is SCHED_FIFO a function of the kernel and libc together?
Any enlightenment would be appreciated.
I've got an app that runs SCHED_FIFO with max priority.
I googled around and found some audio folks picking at the SCHED_FIFO
thing. My Woody system is acting like the SCHED_FIFO is not really
working. On another distro, the SCHED_FIFO does seem to work.
On a Woody box with a 2.4.16 from kernel.org, when I run the
app (myapplicationhere) and the run "ps axeo rtprio,pri,pid,fname", the PRI is
RTPRIO PRI PID COMMAND
- 31 1 init
- 30 2 keventd
- 20 3 ksoftirq
- 30 4 kswapd
- 30 5 bdflush
- 30 6 kupdated
- 30 94 portmap
- 30 100 rpciod
- 30 101 lockd
- 30 152 syslogd
- 30 155 klogd
- 30 160 rpc.stat
- 30 167 inetd
- 30 174 sshd
- 30 177 atd
- 30 180 cron
- 30 183 getty
- 30 184 getty
- 30 185 getty
- 30 186 getty
- 30 187 getty
- 30 188 getty
- 28 707 sshd
- 26 709 bash
- 25 834 myapplicationhere
- 21 869 ps
On another distro with a 2.4.22 that is patch for NPTL, running the same app
(compiled under this distro) I get:
RTPRIO PRI PID COMMAND
0 23 1 init
0 23 2 keventd
0 24 3 kapmd
0 5 4 ksoftirq
0 14 6 bdflush
0 24 5 kswapd
0 24 7 kupdated
0 18 8 mdrecove
0 24 12 kjournal
0 24 67 khubd
0 23 1051 kjournal
0 23 1380 syslogd
0 23 1384 klogd
0 23 1410 portmap
0 21 1429 rpc.stat
0 24 1474 rpciod
0 22 1475 lockd
0 23 1487 apmd
0 22 1525 smartd
0 23 1538 sshd
0 23 1552 xinetd
0 23 1572 sendmail
0 23 1581 sendmail
0 23 1595 crond
0 23 1612 atd
0 21 1621 mingetty
0 21 1622 mingetty
0 21 1623 mingetty
0 21 1624 mingetty
0 21 1625 mingetty
0 20 1626 mingetty
0 24 7631 sshd
0 24 7633 bash
0 23 8538 tail
99 139 8912 myapplicationhere
0 23 8947 ps
I recognize the 99 as the reported max priority value.
Thanks,
--
Mike
Moving forward in pushing back the envelope of the corporate paradigm.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
