> 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 [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
