On Wed, Feb 04, 2015 at 02:39:06PM -0500, Steven Rostedt wrote: > The problem is that if you have 100 CPUs having an RT task schedule out > (just like cyclictest -d0 -t -i100 does a lot), and if there's one rq > that has more than one RT task scheduled on it (overloaded), each > of those 100 CPUs are going to try to get that second RT task on that > lonely rq, and each of those 100 CPUs are going to take that lonely > rq's lock! Then what happens if the task running on that rq wants to > schedule? Well, it needs to wait behind 100 CPUs contending for its rq > lock, and we see a HUGE latency (1ms or more). > > What does this patch do instead? Instead of trying to fight for the rq, > if it sees that there's an overloaded rq, it simply sends an IPI to > that CPU to have it push the overloaded RT task off to another CPU. So can't we flip the problem around; 99 overloaded cpus and 1 going 'low', then we IPI the 99, and they're all going to try and push their tasks on the one (now) sad cpu? -- 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
