Messages in this thread | | | Date | Thu, 29 Aug 2013 22:45:09 +0200 | From | Andreas Mohr <> | Subject | Re: [PATCH] workqueue: defer to waiting stop_machine |
| |
> 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
| |