On Mon, 2012-12-10 at 20:53 -0500, Steven Rostedt wrote: > On Mon, 2012-12-10 at 17:15 -0800, Frank Rowand wrote: > > > I should have also mentioned some previous experience using IPIs to > > avoid runq lock contention on wake up. Someone encountered IPI > > storms when using the TTWU_QUEUE feature, thus it defaults to off > > for CONFIG_PREEMPT_RT_FULL: > > > > #ifndef CONFIG_PREEMPT_RT_FULL > > /* > > * Queue remote wakeups on the target CPU and process them > > * using the scheduler IPI. Reduces rq->lock contention/bounces. > > */ > > SCHED_FEAT(TTWU_QUEUE, true) > > #else > > SCHED_FEAT(TTWU_QUEUE, false) > > > > Interesting, but I'm wondering if this also does it for every wakeup? If > you have 1000 tasks waking up on another CPU, this could potentially > send out 1000 IPIs. The number of IPIs here looks to be # of tasks > waking up, and perhaps more than that, as there could be multiple > instances that try to wake up the same task. Yeah. In mainline, wakeup via IPI is disabled within a socket, because it's too much of a performance hit for high frequency switchers. (It seems we're limited by the max rate at which we can IPI) -Mike -- 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
