On Thu, 16 Jul 2009, Peter Zijlstra wrote: > On Wed, 2009-07-15 at 19:11 -0400, Ted Baker wrote: > > Again, I don't think that either PP or PI is appropriate for use > > in a (SMP) kernel. For non-blocking locks, the current > > no-preeemption spinlock mechanism works. For higher-level > > (blocking) locks, I'm attracted to Jim Anderson's model of > > non-preemptable critical sections, combined with FIFO queue > > service. > > Right, so there's two points here I think: > > A) making most locks preemptible > B) adding PI to all preemptible locks > > I think that we can all agree that if you do A, B makes heaps of sense, > right? > > I just asked Thomas if he could remember any numbers on this, and he > said that keeping all the locks non-preemptible had at least an order > difference in max latencies [ so a 60us (A+B) would turn into 600us (! > A) ], this means a proportional decrease for the max freq of periodic > tasks. That are numbers from about 3 years ago. I need to redo the tests as we did lot of lock breaks and shortening of preempt/irq disabled sections since then, but when we started preempt-rt there was no real choice as the limited number of developers simply did not allow to analyse and fix all the long lasting critical sections. We were busy enough to fix all the locking problems which were unearthed. :) Also we did not have the tools to analyse the length of critical sections back then. It's definitely worthwhile to revisit this, but that's going to be a multi man years effort to distangle complex code pathes like the network stack, disk i/o and other known sources of trouble. The next challenge will be how to monitor the code base for regressions and keeping thousands of developers aware of these requirements. > This led to the conviction that the PI overheads are worth it, since > people actually want high freq tasks. > > Of course, when the decreased period is still sufficient for the > application at hand, the non-preemptible case allows for better > analysis. Agreed, but the real challenge of providing real time services in Linux is the wide variety of use cases. We simply need to accept that people want to use it from high frequency industrial control tasks while running a GUI, a webserver and a database on the same machine to heavily threaded enterprise class Java applications which do not care that much about latencies but need the correctness guarantees and of course everything in between. I'm well aware that we try to create something which does everything except of playing the National Anthem, but simply restricting the use cases is not an option and would be exceptionally boring as well :) Thanks, tglx -- 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
