On 04/10/2014 04:44 PM, Clark Williams wrote: > The means of each group of five test runs are: > > vanilla.log: 1210117 rt.log: 17210953 (14.2 x slower than > vanilla) rt-fixes.log: 10062027 (8.3 x slower than vanilla) > rt-multi.log: 3179582 (2.x x slower than vanilla) > > > As expected, vanilla kicked RT's butt when hammering on the > mmap_sem. But somewhat unexpectedly, your fixups helped quite a > bit and the multi+fixups got RT back into being almost > respectable. > > Obviously these are just preliminary results on one piece of h/w > but it looks promising.
Is it easy to look at the latency when you have multiple readers and and a high prio writer which has to boost all those readers away instead just one? Or is this something that should not happen for a high prio RT task because it has all memory already allocated? > > Clark Sebastian -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
