As we know that the QNX using default priority 21 for interrupt handling. Therefore, is it suitable to set my custom application to priority higher than 21? I worry about that it could lead to io-net and network driver miss the interrupt. I would consider default priority for user application is 20 to 10. It is due to priority 21 is for both network driver interrupt handling, io-usb, devb-eide, and so on. Moreover, priority 10 is for almost QNX utility such as slogger and so on.
In another way, I am considering to use ‘io-net -di82544 priority 50’ and ‘renice’ to adjust network driver interrupt handling and io-usb/devb-eide priority to 50. However, the io-usb/devb-eide has no luck with ‘renice’ commands still remain in 21. Therefore, I can not have priority ranges for user applications from 49 to 10.
Had you done above two approaches before? Please correct me if I am wrong.
Well yes and no. There are systems that implement priorities this way, however to the best of my knowledge, there is no thread priority the way you describe it. Every thread has a system relative priority. A process with multiple threads running at the same priority could develop a scheme where there is also an internal priority, so that only the highest priority thread thread would run, but this would be voluntary on their part.
As QNX scheduling is per thread not per process, why there will be an internal priority?
Maybe I need to explain more about the reason for asking this question.
In brief, the QNX default interrupt handling 21 for io-net, io-usb, devb-eide, and so on, which will lead to only priority from 20 to 10 for user applications. This is not enough priority levels for user applications. For example, if there are 10 applications and each has 5 threads, and each application need higher level than others, there will be 50 priority levels required. However, user application should not higher than interrupt handling, it will lead to insufficient priority levels for user applications.
Priority levels determine which thread has control of the CPU when more than one is ready to run. In principle you might need a different priority for every thread. Practically speaking, this is very unlikely. To begin with, in most systems, the majority of the cpu is used running an idle loop. There are exceptions and I can’t rule that out for your system. So any thread that is not deemed critical will be perfectly happy sharing time slices with all other such threads. It seems very unlikely that you have 50 different threads whose resource access to the processor needs to be enumerated precisely. I should say unlikely but not impossible.
You might also take a look at raising the interrupt priority of the processes you mention.
Well, our target is ported from a legacy system, which have 10 applications each running on a 20MHz ARM processor concurrent (e.g. parallel processing). Each application has 5 threads of itself. In brief, we integrate all 10 applications into 1GHz x86 processor. That is why 50 thread priority levels request come from. (The total cpu usage of x86 is about 10% shows that cpu computing power is enough)
After review, we had tried to simplify the thread priority to 30 levels (4 of 10 applications does not require high priority). But the request of 30 priority levels is still higher than QNX default 10 levels.
Since QNX had been widely used, there should have users with similar problems. That is why I can not understand QNX default interrupt priroity to 21, instead of default higher value between 21 to 255? QNX kernel is priority 255, and there is a lot of space range, isn’t it? Is there some special reason or workaround?
Yes it does seems strange that the default priority is 20/21. You have to understand that only 1 thread of each of the mention program is actually at that priority, in most case the other threads are working threads that will take on the priority of the thread/process that made a request.
Since by default threads will float to the priority of the event they receive, using nice/renice won’t affect the priority of these internal event.
devb-eide has the priority option, netdriver have a pri option, I didn’t find one for io-usb drivers.
note that most program will inherit the priority of their parent, hence if you configure the boot image to load the sysinit script at priority 2 everything program that don’t set their own priority will have priority 2.
Why do say this? Having the default interrupt pulse priority for these drivers set to 21 implies nothing other than that. You can set a user thread to priority 255 (of course it will pre-empt the interrupt threads, but that is the idea). If you want higher priorities for the interrupt pulses, then every driver has a keyword to set this (check the docs).
There is no general rule that says user application threads can’t have a priority higher than an interrupt thread. It depends on the application.
Not really… think about it… this entire thread is due to the common misconception (imbued in users by inferior O/S’s that interrupt handlers must always be a higher priority than user threads. Since every application requires an individual RMA, having the defaults for the drivers at an obviously low (but perfectly functional) priority makes people think (just like is happening here).
That’s because usb “drivers” aren’t actually drivers, just “class handlers”; however io-usb does have an option to set the pulse priority (-P).
I didn’t say that they have to be higher then user application. I’m saying that the default 20/21 is kind of low. If one chooses to run all of its code below that, that only leaves 9 priorities. Of course you can change this by building your own image. However given there is 255 priority should these important thread be closer to 255 then to 0 by default.
Please correct me if I am wrong: Due to priority scheduling is let highest priority finish its job fastest, ‘generally’ (not special case) the interrupt handler should be higher than user application. Otherwise, interrupt handler might have chance not being processed before second interrupt arrival.
BTW, the docs of io-usb neither mention the ‘-P’ is for pulse priority nor says that its pulse priority can be change.
Of course that interrupt handler priority can be changed for network driver. However, there are still some service or drivers (such as devb-eide, io-usb, io-hic, mqueue, inetd, etc) have their own thread priority. Therefore, it is some kind of risky to only changing the interrupt handler priority of network driver and left other driver/services as default. I hope that QNX can publish a guideline or technical article about “priority level shortage” …
There is no priority level shortage. QSSL can’t possibly determine what priority your threads should be, that’s your job (as the real-time application developer) to determine. Everything is settable by the user (if you find a case where it isn’t then file a PR).
Of course determining thread priority is job of user. However, as I know, not every QNX service priority can be adjusted (for example, io-hid and io-usb). If not every service can be adjusted, how could user adjust them?
If you find any service for which the priority can not be adjusted, then file a PR. Since the source is open, you can also fix it. io-usb definitely allows setting of priorities, and io-hid isn’t actually a driver, so it doesn’t need to AKAIK.
If the priority isn’t settable, that’s a bug; but the value of default priorities can’t be a bug, since they are arbitrary in any case.
that interrupt handlers must always be a higher priority than user threads. Since every application requires an individual RMA, having the defaults for the drivers at an obviously low (but perfectly functional) priority makes people think (just like is happening here).