On Mon, 2013-03-18 at 09:27 -0700, Tejun Heo wrote: > Does that mean that a task holding gcwq->lock may be preempted? If > so, that sure could lead to weird problems. Maybe gcwq->lock should > be marked non-preemptible somehow? If the gcwq->lock is never held for a long time (really, more than a microsecond on today's processors is considered a long time), and it does not nest any other spin_locks (raw locks are OK, like the rq lock). Then we could mark the gcwq->lock as raw as well. This would require the struct global_cwq lock to have: raw_spinlock_t lock; and then you would need to do: s/spin_/raw_spin/ for all gcwq->lock usages. But, I'm worried about the loops that are done while holding this lock. Just looking at is_chained_work() that does for_each_busy_worker(), how big can that list be? If it's bound by # of CPUs then that may be fine, but if it can be as big as the # of workers assigned, with no real limit, then its not fine, because that creates an unbound (non deterministic) latency. -- Steve -- 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
