Hello, Johannes. On 11/18/2010 08:07 AM, Johannes Berg wrote: >> I see. In the longer run tho, it would be much better to convert to >> NRT workqueue. The behavior would be more robust with much lower >> latencies. > > I really don't think it's possible without going to some scheme > where we use a single work struct and kick off things out of it, > or implement our own threading or similar things ... I see. > 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. > 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. Thanks. -- tejun -- 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
