The QNX helpfile documentation indicates that
“sched_get_priority_max” is unsupported. And there doesn’t seem
to be a “sched_set_priority_max”. Is it possible to limit the
ability of a process to increase its priority?
John Nagle
Team Overbot
John Nagle <nagle@downside.com> wrote:
The QNX helpfile documentation indicates that
“sched_get_priority_max” is unsupported. And there doesn’t seem
to be a “sched_set_priority_max”. Is it possible to limit the
ability of a process to increase its priority?
I don’t think so.
-David
QNX Training Services
http://www.qnx.com/support/training/
Please followup in this newsgroup if you have further questions.
I think sched_get_priority_max() is supported, as I am using it. There’s no
‘set_priority_max’, the purpose of the ‘get’ call is to find out valid range
of priorities for a given scheduling class on a given OS (if you set invalid
priority, sched_setscheduler() will fail, but which one is valid is
OS-dependent, so POSIX defines get_min() and get_max() calls).
There’s no way to limit your priority other than running as non-root (then
you can’t go above 19 I think).
– igor
“John Nagle” <nagle@downside.com> wrote in message
news:3F2DF7CC.7020200@downside.com…
The QNX helpfile documentation indicates that
“sched_get_priority_max” is unsupported. And there doesn’t seem
to be a “sched_set_priority_max”. Is it possible to limit the
ability of a process to increase its priority?John Nagle
Team Overbot
Igor Kovalenko <kovalenko@attbi.com> wrote:
I think sched_get_priority_max() is supported, as I am using it. There’s no
‘set_priority_max’, the purpose of the ‘get’ call is to find out valid range
of priorities for a given scheduling class on a given OS (if you set invalid
priority, sched_setscheduler() will fail, but which one is valid is
OS-dependent, so POSIX defines get_min() and get_max() calls).
QNX doesn’t limit priorities by scheduling class. The same maximum
(63) applies to all types.
There’s no way to limit your priority other than running as non-root (then
you can’t go above 19 I think).
That was true under QNX 4, but is not under QNX 6.
Any thread can set its priority anywhere in the range 1-63.
I think, with the release of QNX Neutrino 6.3, that the priority
range will be extended to 0-255, and that 63 will be the limit
of non-root threads.
-David
QNX Training Services
http://www.qnx.com/support/training/
Please followup in this newsgroup if you have further questions.
“David Gibbs” <dagibbs@qnx.com> wrote in message
news:bhqne8$28u$1@nntp.qnx.com…
Igor Kovalenko <> kovalenko@attbi.com> > wrote:
I think sched_get_priority_max() is supported, as I am using it. There’s
no
‘set_priority_max’, the purpose of the ‘get’ call is to find out valid
range
of priorities for a given scheduling class on a given OS (if you set
invalid
priority, sched_setscheduler() will fail, but which one is valid is
OS-dependent, so POSIX defines get_min() and get_max() calls).QNX doesn’t limit priorities by scheduling class. The same maximum
(63) applies to all types.
The QNX behavior here is not conforming to POSIX. It allows threads with
SCHED_OTHER to compete for CPU time with SCHED_RR and SCHED_FIFO (which are
reserved for realtime threads). Or to put it another way, there is no way to
portably start a realtime thread at a priority that’s higher than any
non-realtime thread. It is inconvinient and does not really match semantics
of POSIX specs. The whole idea of this API was that you just call
‘sched_get_priority_min()’ and pass value into ‘sched_setscheduler()’ and
that guarantees you won’t be bothered by non-realtime jobs. POSIX-compliant
code may legally rely on this behavior but it would be broken on QNX.
I think the SCHED_OTHER on QNX should be limited to 0-19, and other methods
should start higher. That way it will match behavior of ‘nice’, that does
not let you raise priority by more than 9 (so maximum is 19 for default
shell started with 10).
There’s no way to limit your priority other than running as non-root
(then
you can’t go above 19 I think).That was true under QNX 4, but is not under QNX 6.
Any thread can set its priority anywhere in the range 1-63.
Oh, so you have removed whatever little safety measure was there…
I think, with the release of QNX Neutrino 6.3, that the priority
range will be extended to 0-255, and that 63 will be the limit
of non-root threads.
The 63 is still pretty high and given that most standard drivers/managers
run below that, still leaves system vulnerable to be knocked down by anyone
who’s got a login shell. I don’t think non-root processes should be allowed
to raise priority above the lesser of their parents or the maximum allowed
for given scheduling class .
But of course, making you guys change your mind about anything at all,
even something obviously broken, is known to be an excersize in futility.
– igor
Igor Kovalenko <kovalenko@attbi.com> wrote:
IK > The 63 is still pretty high and given that most standard drivers/managers
IK > run below that, still leaves system vulnerable to be knocked down by anyone
IK > who’s got a login shell. I don’t think non-root processes should be allowed
IK > to raise priority above the lesser of their parents or the maximum allowed
IK > for given scheduling class .
IK > But of course, making you guys change your mind about anything at all,
IK > even something obviously broken, is known to be an excersize in futility.
IK > – igor
I don’t mean to start a religious argument. But I like it when the OS
provides me, the system integrator, more versitility. If you want to
impose restrictions above an beyond what the OS imposes, you can just
provide a cover function for whatever functions you want greater
restrictions on and then add a define to call your function instead of
the real one.
If the POSIX spec calls for this restriction, then the QNX
implimentation is broken. But I like their broken version better.
Igor Kovalenko <kovalenko@attbi.com> wrote:
“David Gibbs” <> dagibbs@qnx.com> > wrote in message
news:bhqne8$28u$> 1@nntp.qnx.com> …
Igor Kovalenko <> kovalenko@attbi.com> > wrote:
I think sched_get_priority_max() is supported, as I am using it. There’s
no
‘set_priority_max’, the purpose of the ‘get’ call is to find out valid
range
of priorities for a given scheduling class on a given OS (if you set
invalid
priority, sched_setscheduler() will fail, but which one is valid is
OS-dependent, so POSIX defines get_min() and get_max() calls).QNX doesn’t limit priorities by scheduling class. The same maximum
(63) applies to all types.
The QNX behavior here is not conforming to POSIX. It allows threads with
SCHED_OTHER to compete for CPU time with SCHED_RR and SCHED_FIFO (which are
reserved for realtime threads).
Where in the POSIX spec do you find support for this?
In looking at POSIX 1003.1-2001, System Interfaces, Realtime (2.
,
definition for SCHED_OTHER, it says,
“Conforming implementations shall include one scheduling policy
identified as SCHED_OTHER (which may execute identically with
either the FIFO or round robin scheduling policy).”
This exactly describes QNX Neutrino’s implementation – SCHED_OTHER
is identical to round robin.
It further continues,
“The effect of scheduling with the SCHED_OTHER policy in a system in which
other threads are executing under SCHED_FIFO, SCHED_RR, or SCHED_SPORADIC
is implementation defined.”
Awful hard for us to be non-conforming in our SCHED_OTHER behaviour
when POSIX defines the behaviour as implementation defined.
Or to put it another way, there is no way to
portably start a realtime thread at a priority that’s higher than any
non-realtime thread.
You’re right, there is no such portable way. From my reading, POSIX
does not define a portable way.
Also, POSIX does say, earlier in this section, that “The priority
ranges for each policy may but need not overlap the priority ranges
for other policies.”
So, we’re ok there too.
POSIX may say that realtime scheduling policies must pre-empt
non-realtime policies, but QNX does not supply any non-realtime
scheduling policies. And, I don’t think POSIX does mandate the
existence for non-realtime scheduling policies.
There’s no way to limit your priority other than running as non-root
(then
you can’t go above 19 I think).That was true under QNX 4, but is not under QNX 6.
Any thread can set its priority anywhere in the range 1-63.
Oh, so you have removed whatever little safety measure was there…
And, as I noted, put it back in for 6.3.
I think, with the release of QNX Neutrino 6.3, that the priority
range will be extended to 0-255, and that 63 will be the limit
of non-root threads.The 63 is still pretty high and given that most standard drivers/managers
run below that, still leaves system vulnerable to be knocked down by anyone
who’s got a login shell.
Under QNX 4, you had 2/3 of the priority spectruum for user processes, 1/3
reserved for root only.
Under QNX 6.3, you have 1/4 of the priority spectruum for user processes,
and 3/4 reserved for root only.
I don’t think non-root processes should be allowed
to raise priority above the lesser of their parents or the maximum allowed
for given scheduling class .
That would break nice/renice among other things.
-David
QNX Training Services
http://www.qnx.com/support/training/
Please followup in this newsgroup if you have further questions.
“David Gibbs” <dagibbs@qnx.com> wrote in message
news:bhtlvq$k9o$1@nntp.qnx.com…
Igor Kovalenko <> kovalenko@attbi.com> > wrote:
“David Gibbs” <> dagibbs@qnx.com> > wrote in message
news:bhqne8$28u$> 1@nntp.qnx.com> …
Igor Kovalenko <> kovalenko@attbi.com> > wrote:
I think sched_get_priority_max() is supported, as I am using it.
There’s
no
‘set_priority_max’, the purpose of the ‘get’ call is to find out
valid
range
of priorities for a given scheduling class on a given OS (if you set
invalid
priority, sched_setscheduler() will fail, but which one is valid is
OS-dependent, so POSIX defines get_min() and get_max() calls).QNX doesn’t limit priorities by scheduling class. The same maximum
(63) applies to all types.
The QNX behavior here is not conforming to POSIX. It allows threads with
SCHED_OTHER to compete for CPU time with SCHED_RR and SCHED_FIFO (which
are
reserved for realtime threads).Where in the POSIX spec do you find support for this?
In looking at POSIX 1003.1-2001, System Interfaces, Realtime (2.>
definition for SCHED_OTHER, it says,“Conforming implementations shall include one scheduling policy
identified as SCHED_OTHER (which may execute identically with
either the FIFO or round robin scheduling policy).”
It may, but commonly is not. It is commonly left for non-realtime
scheduling. True, POSIX does not mandate any certain interpretation of
SCHED_OTHER, but unless they had some idea what it could be used for, why on
Earth did they even put it in the spec? And used strong wording (‘shall’)?
Could it be that they meant ‘we do not impose any meaning on SCHED_OTHER,
other than it is non-realtime’?
This exactly describes QNX Neutrino’s implementation – SCHED_OTHER
is identical to round robin.
Which is, as we have heard on many occasions, a temporary situation.
It further continues,
“The effect of scheduling with the SCHED_OTHER policy in a system in which
other threads are executing under SCHED_FIFO, SCHED_RR, or SCHED_SPORADIC
is implementation defined.”Awful hard for us to be non-conforming in our SCHED_OTHER behaviour
when POSIX defines the behaviour as implementation defined.
You’re ignoring one important thing - POSIX is largely a generalisation of
existing Unix interfaces and practices. Some things are not stated
explicitly because they have been assumed to be a common sense and/or
existing practice. Whenever you’re implementing some standard, the ultimate
goal is not just be formally conforming. Being conforming to XYZ does not
buy anyone anything, if every other guy choses the least useful
interpretation of XYZ. If you want your much touted POSIX compliance to
actually be useful then you should chose some more useful interpretation.
The ultimate goal of being POSIX-compliant is to allow code portability
(and, by implication, allow customers to reuse skills of their developers
familiar with POSIX).
Or to put it another way, there is no way to
portably start a realtime thread at a priority that’s higher than any
non-realtime thread.You’re right, there is no such portable way. From my reading, POSIX
does not define a portable way.
If you chose to not overlap priority ranges, it would be possible, if not
universally then at least among widely used systems. You’d be compatible
with Linux (and who cares much about other Unixes these days).
Also, POSIX does say, earlier in this section, that “The priority
ranges for each policy may but need not overlap the priority ranges
for other policies.”
So you chose to do what you ‘not need’ to. Let’s see what other systems
do…
Linux does not overlap… Solaris has two layers of ‘scheduling class’ - one
from POSIX and their own (Time Share, System, Realtime). They allow
SCHED_OTHER to overlap with SCHED_RR but they are relative to Solaris
scheduling classes. The realtime apps are generally started through
‘priocntl -e -cRT’ that puts them into Realtime class, so their priority
(that you passed) gets added to RT class base (higher than anything else).
So yes, they do it differently… yet it is possible to do what I said using
the same code (even though using command line tricks) on both systems. But
not on QNX, not even using command line tricks.
So, we’re ok there too.
Sure. But just ‘ok’, nothing more.
POSIX may say that realtime scheduling policies must pre-empt
non-realtime policies, but QNX does not supply any non-realtime
scheduling policies. And, I don’t think POSIX does mandate the
existence for non-realtime scheduling policies.
POSIX does not mandate a lot of things. You can return ENOSYS for half of
useful calls and claim being POSIX-compliant (like you do for POSIX async
I/O). If you were VxWorks, I’d understand your position here. But QNX is
playing in different field. You’re self-hosted and you’re trying to convince
people that you’re close enough to Linux. Whether POSIX mandates it or not,
you need to have a non-realtime policy.
There’s no way to limit your priority other than running as non-root
(then
you can’t go above 19 I think).That was true under QNX 4, but is not under QNX 6.
Any thread can set its priority anywhere in the range 1-63.
Oh, so you have removed whatever little safety measure was there…And, as I noted, put it back in for 6.3.
I think, with the release of QNX Neutrino 6.3, that the priority
range will be extended to 0-255, and that 63 will be the limit
of non-root threads.The 63 is still pretty high and given that most standard
drivers/managers
run below that, still leaves system vulnerable to be knocked down by
anyone
who’s got a login shell.Under QNX 4, you had 2/3 of the priority spectruum for user processes, 1/3
reserved for root only.Under QNX 6.3, you have 1/4 of the priority spectruum for user processes,
and 3/4 reserved for root only.I don’t think non-root processes should be allowed
to raise priority above the lesser of their parents or the maximum
allowed
for given scheduling class .That would break nice/renice among other things.
That’s because nice and renice in QNX work with absolute priority. All
Unixes have notion of ‘static’ and ‘dynamic’ (adjusted) priority. That’s
what nice and renice there play with, AFAIK. QNX actually has both
priorities defined in the struct sched_param (not sure what for), so if your
nice & renice worked with ‘dynamic’ (which would be useful if you had
non-realtime SCHED_OTHER) then only ‘static’ would be restricted and nothing
would break.
There’s a simpler way to fix this for 6.3 though. Since you’re adding a
whole new range of priorities that was not used by anything so far, you can
safely restrict SCHED_OTHER to 63 and start SCHED_RR and SCHED_FIFO from 64.
You may need to modify your drivers/managers to set priority properly, but
that’s not a hard thing to do. If they were written carefully in the first
place, they’d be using sched_get_priority_min(SCHED_RR)+offset anyway. And
if they were not, it is never too late to do it right 
– igor
Igor Kovalenko <kovalenko@attbi.com> wrote:
[Lots-O-Interesting Stuff Deleted]
IK > That’s because nice and renice in QNX work with absolute priority. All
IK > Unixes have notion of ‘static’ and ‘dynamic’ (adjusted) priority. That’s
IK > what nice and renice there play with, AFAIK. QNX actually has both
IK > priorities defined in the struct sched_param (not sure what for), so if your
IK > nice & renice worked with ‘dynamic’ (which would be useful if you had
IK > non-realtime SCHED_OTHER) then only ‘static’ would be restricted and nothing
IK > would break.
IK > There’s a simpler way to fix this for 6.3 though. Since you’re adding a
IK > whole new range of priorities that was not used by anything so far, you can
IK > safely restrict SCHED_OTHER to 63 and start SCHED_RR and SCHED_FIFO from 64.
IK > You may need to modify your drivers/managers to set priority properly, but
IK > that’s not a hard thing to do. If they were written carefully in the first
IK > place, they’d be using sched_get_priority_min(SCHED_RR)+offset anyway. And
IK > if they were not, it is never too late to do it right
There are two issues here, handeling real-time and SCHED_OTHER. As the
programmer/system implementer I can make any thread real-time by
putting it’s priority above any non-real-time threads. I don’t see the
big deal here.
I liked the QNX4 implementation on SCHED_OTHER. Sometimes you want a
process to be high enough in priority to be responsive to a user until
it enters a compute bound process. I.E. an editor that is doing a large
sort for the moment.
I’ve developed multi-channel PCI audio device drivers while working at
Orban. We were able to play up to 24 stereo channels (48 mono channels)
of linear data from a single Pentium-166. I put the device driver for
that device at priority 29 and moved Proc down to 26. We never once
missed a single beat, no matter how much other stuff was happening on
that system. And there was quite a lot.
Real-time is not hard to achieve. You just have to code for it.
If your issue is getting 100% portable code from RTP and Linux it just
ain’t gonna happen!
“Bill Caroselli” <qtps@earthlink.net> wrote in message
news:bhvse5$scu$1@inn.qnx.com…
Igor Kovalenko <> kovalenko@attbi.com> > wrote:
[Lots-O-Interesting Stuff Deleted]
There are two issues here, handeling real-time and SCHED_OTHER. As the
programmer/system implementer I can make any thread real-time by
putting it’s priority above any non-real-time threads. I don’t see the
big deal here.
But not in portable way. For you it’s not a big deal, for me it is.
I liked the QNX4 implementation on SCHED_OTHER. Sometimes you want a
process to be high enough in priority to be responsive to a user until
it enters a compute bound process. I.E. an editor that is doing a large
sort for the moment.
Everyone liked it. But it was not realtime, lol.
I’ve developed multi-channel PCI audio device drivers while working at
Orban. We were able to play up to 24 stereo channels (48 mono channels)
of linear data from a single Pentium-166. I put the device driver for
that device at priority 29 and moved Proc down to 26. We never once
missed a single beat, no matter how much other stuff was happening on
that system. And there was quite a lot.Real-time is not hard to achieve. You just have to code for it.
If your issue is getting 100% portable code from RTP and Linux it just
ain’t gonna happen!
It surely ain’t gonna happen if everyone takes position like you and just
keep saying ‘it ain’t gonna happen’. Why don’t you want to let it happen?
One step at a a time…
– igor