Hello, Neil. (cc'ing Lai)
On Fri, Nov 20, 2020 at 10:07:56AM +1100, NeilBrown wrote: > If the workqueue maintainers are unmovable in the position that a > CM-workitem must not use excessive CPU ever, and so must not call > cond_resched(), then I can take that back to the NFS maintainers and Oh, that's not my position at all. I'm completely movable and am pretty sure Lai would be too. > negotiate different workqueue settings. But as I've said, I think this > is requiring the decision to be made in a place that is not well > positioned to make it. Very true. A lot of the current workqueue code is a result of gradual evolution and has a lot of historical cruft. Things like CPU_INTENSIVE or long_wq were introduced partly to facilitate existing users to CM workqueue and definitely are silly interfaces as you mentioned in another reply. I can see two directions: 1. Keeping things mostly as-is - leave the selection of the specific workqueue type to users. We can improve things by adding debug / sanity checks to surfaces issues more proactively, adding more documentation and cleaning up old cruft. 2. Make things properly dynamic. By default, let workqueue core decide what type of execution constraints are gonna be applied and dynamically adjust according to the behavior of specific workqueues or work items. e.g. it can start most work items CM per-cpu by default and then release them as unbound when its cpu consumption exceeds certain threshold. #1 is easier. #2 is definitely more attractive long term but would need a lot of careful work. I was suggesting towards #1 mostly because it's a safer / easier direction but if you wanna explore #2, please be my guest. Thank you. -- tejun
