On Thu, 2010-11-18 at 08:22 +0100, Tejun Heo wrote: > > But why is this unreliable and/or high latency anyway? > > Oh, no, it's not unreliable or high latency on workqueue side. It's > just error prone for its users. As there is only single executino > resource by definition, any single work can stall the whole queue and > it also is easy to create a deadlock by introducing circular > dependency. For example, mac80211 uses system wq for restart work and > that's to avoid grabbing rtnl_lock from a work as that will introduce > a deadlock, right? If you use non-ordered workqueues, you don't need > to worry about those artificial dependencies. Ok, that makes sense then. I thought you were saying there was some intrinsic issue with this! I do know about the issues, but we do have to process some things in the right order here so I'd rather be aware of those issues than have to deal with reordering and/or our own queueing. > > It used to be just fine .. maybe this is one of the cases where we > > should actually be using a dedicated thread ... > > Oh, trust me, that won't change anything. If there's a bug in > workqueue (I don't think this is the case here tho), let's fix it. If > mac80211 is somehow tripping a deadlock around single execution > resource, let's fix the culprit. Okay? At this point, all we need is > a proper task dump to see who's holding what where. I agree completely -- just misunderstood you there! johannes -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
