Hi Andreas, Just calling cond_resched() does appear to be the more general solution, and is already on tj/wq/for-next as b22ce2785d97423846206cceec4efee0c4afd980 "workqueue: cond_resched() after processing each work item".
Thanks, Jamie On Thu, Aug 29, 2013 at 1:45 PM, Andreas Mohr <a...@lisas.de> wrote: >> Isn't the problem that the kworker wouldn't yield to the higher >> priority stopper task while a work item keeps requeueing itself if >> preemption is not enabled? If so, isn't the correct solution just >> adding cond_resched() in the work item processing loop? The analysis >> and solution seem to have gone a bit stray.... > > While I did not quite follow the very fine and detailed analysis, > I had the same feeling about it. > > The previous solution seemed less preferable e.g. for two reasons, > from a modularity/dependency POV: > - required a very specific (code smell?) stop_machine handling dependency > in work queue code (machine stop handling arguably definitely > is a corner case, and thereby supposed to remain just that!) > - new stop_machine_pending() helper is pretty bloated, > and called in a semi-hotpath to boot (since it's using && operators > rather than ||, seems like it would be called pretty much every time) > > Preemption checks being expected to be much more general and widespread > thus seems like a much better fit. > > > Or, to put it another way, could it be that that extra very specific > stop_machine check was simply added since due to missing preemption checks > we were busy-handling there and thus not getting back to standard handling > areas > where some *usual*, *hotpath/mainstream* stop_machine checks would have been > made? > If so, perhaps there actually are some other cases of wasteful stop_machine > check > code sites in the kernel where instead we could simply have a much cheaper > reschedule done, thereby go back to hitting one central (and thus cache-hot) > code site with stop_machine check etc.? > > > Afraid of having stated the glaringly obvious ;), > > Andreas Mohr -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
