* Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx> wrote: > > So if it's generic it ought to be implemented in a generic way - not a > > "dont use from any codepath that has a lock held that might > > occasionally also be held in a keventd worklet". (which is a totally > > unmaintainable proposition and which would just cause repeat bugs > > again and again.) > > That's different. The core fault here lies in the keventd workqueue > handling code. If we're flushing work A then we shouldn't go and block > behind unrelated work B. the blocking is inherent in the concept of "a queue of worklets handled by a single thread". If a worklet is blocked then all other work performed by that thread is blocked as well. So by waiting on a piece of work in the queue, we wait for all prior work queued up there as well. The only way to decouple that and to make them independent (and hence independently flushable) is to create more parallel flows of execution: i.e. by creating another thread (another workqueue). Ingo -- To unsubscribe from this list: send the line "unsubscribe cpufreq" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
