Hi, >> So, in that case and in many other hotplug cases, you ruin the RT >> behaviour of the system just by the >> default-50-is-probably-right-assumption of the kernel. >> For systems where you have everything under control as a user/system >> designer, hotplug can also be under control as well. >> > > I dont't quite see that - the 50 default is well dokumented so you can > plan it into the rt design at system level. It simply means that you > would need to put your hard-rt tasks in the range of 50<prio<99. This is another assumption as well. You assume here that any task bound to certain latencies must be above _all_ interrupt handlers, and tasks not bound to certain latencies must be set below _all_ interrupt handlers. In fact, in real life, the prioritisation will be much more fine grained during runtime. One can have a RT task that depends on the networking stack, but not on mass-storage. In that case you want to move them out of the range of 50. The whole idea about threaded interrupts is, is that you can give them priorities such that they suit your specific application. It is therefore common practice that priorities does not stay at 49/50. In real life you may want, for EXAMPLE, this setup: * prio 70: high priority motor control loop * prio 60: network device irq * prio 59: network softirqs * prio 55: some realtime task depending on networkingstack * prio 54: mass storage irq * prio 53: block device softirq * prio 52: some realtime task depending on mass-storage * prio 50: all remaining irq threads * prio 49: all remaining softirqs Assume here you do a ifconfig down and ifconfig up, in the current kernel behaviour you will see that the irq thread switches from prio 60 to 50. The irq-thread will become of a lower priority compared to its related softirqs due to this reason, which can result in a complete die of this network interface... even before it ever came back up again... As mentioned before by Thomas, the configuration is a policy issue and must be set from user-context. I understand what he means by that and I agree, but there still has to be a mechanism to make the kernel remember the configuration set by the user to prevent all kinds of race conditions. You cannot demand from the user to run after executing a shell command like ifconfig or modprobe to run some sort of init-script that repairs what the kernel assumed wrong. The wrong assumptions the kernel does results in: deadlocks, priority inversion issues between irq-threads and softirqs and realtime behaviour impact. Even UDEV cannot_fix_this_problem_ since it runs _after_ the kernel has set the wrong priorities of the irq threads and the problem it imposes already may have occurred. Setting the priorities right once is already complicated enough, it makes it far more complex if all kinds of race conditions and limitations need to be taken into account due to this mentioned auto-reset-to-50(-or-1)-assumptions of the kernel... True, there must be a safe default for booting, and 49/50 is good enough for that. So, you might disagree the way our patches to solve this problem are implemented, I can buy that, it is just at the level of 'works-for-me' . Since this discussion frequently appears back on the mailinglist makes clear that this _is_ an issue that is relevant. Instead of ignoring or denying this issue, we should figure out what is the _best_way_ to solve it. I hope to see great and constructive suggestions soon on this list, I am very willing to implement it :-) Kind regards, Remy -- To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
