On Fri, 2011-07-22 at 19:45 +0200, Nicholas Mc Guire wrote: > > Therefore the worst case latency is in the order of > > max-migrate-disable-period * nr-cpus. > > + something like sum of (interrupt rate [n] / > max-migrate-disable-period * nr-cpus) * top-half handler [n]. if you > go on with theoretical WCET analysis on multicore systems you will > always end up at the conclusion that only UP is suitable for RT.... + preemption cost + migration costs etc.. :-) > > Currently we have no means of measuring these latencies, this is > > something we need to grow, I think Steven can fairly easy craft a > > migrate_disable runtime tracer -- it needs to use t->se.sum_exec_runtime > > for measure so as to only count the actual time spend on the task and > > ignore any time it was blocked. > > well this is a similar problem as with the WCET "calculations" - you can > calculate theoretical worst cases - but the question is what the actual > distribution of "stacking" is and thus what the probability is that you > manage to stack tasks in this way. Sure, and yes those are thing to look at. > One could I guess put some relatively simple instrumentation in to monitor > this stacking problem - quit independant of actually measuring the times Yes, that would be very easy to do. > > Once we have this, its back to the old game of 'lock'-breaking. > > > if the stacking problem does not practically exist then it might not be worth > the effort to resolve it with elaborate lock breaking. Fully agreed, its just that I wanted to share my understanding of the problem space (both Thomas and I thought on-list email was a better location that private IRC logs ;-), and we need to get the know the problem before we can decide to ignore it ;-) Ignoring unknowns always leads to surprises. -- 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
