Ingo Molnar wrote: > So why do your "ping flood" results show such difference? It really is > just another type of interrupt workload and has nothing special in it. ... > are you suggesting this is not really a benchmark but a way to test how > well a particular system withholds against extreme external load?
Look, you're basically splitting hairs. No matter how involved an explanation you can provide, it remains that both vanilla and I-pipe were subject to the same load. If PREEMPT_RT consistently shows the same degradation under the same setup, and that is indeed the case, then the problem is with PREEMPT_RT, not the tests. > so you can see ping packet flow fluctuations in your tests? Then you > cannot use those results as any sort of benchmark metric. I didn't say this. I said that if fluctuation there is, then maybe this is something we want to see the effect of. In real world applications, interrupts may not come in at a steady pace, as you try to achieve in your own tests. > and from this point on you should see zero lmbench overhead from flood > pinging. Can vanilla or I-PIPE do that? Let's not get into what I-pipe can or cannot do, that's not what these numbers are about. It's pretty darn amazing that we're even having this conversation. The PREEMPT_RT stuff is being worked on by more than a dozen developers spread accross some of the most well-known Linux companies out there (RedHat, MontaVista, IBM, TimeSys, etc.). Yet, despite this massive involvement, here we have a patch developed by a single guy, Philippe, who's doing this work outside his regular work hours, and his patch, which does provide guaranteed deterministic behavior, is: a) Much smaller than PREEMPT_RT b) Less intrusive than PREEMPT_RT c) Performs very well, as-good-as if not sometimes even better than PREEMPT_RT Splitting hairs won't erase this reality. And again, before the I get the PREEMPT_RT mob again on my back, this is just for the sake of argument, both approaches remain valid, and are not mutually exclusive. Like I said before, others are free to publish their own numbers showing differently from what we've found. Karim -- Author, Speaker, Developer, Consultant Pushing Embedded and Real-Time Linux Systems Beyond the Limits http://www.opersys.com || [EMAIL PROTECTED] || 1-866-677-4546 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/