Hello, On Sat, Mar 19, 2022 at 11:02:51AM +0900, Tetsuo Handa wrote: > Is the intent of __WQ_LEGACY flag to indicate that "this WQ was created > using deprecated interface" ? But such intention no longer holds true. > > Despite __WQ_LEGACY flag is described as "internal: create*_workqueue()", > tegra194_cpufreq_probe()/scsi_add_host_with_dma()/iscsi_host_alloc()/ > iscsi_transport_init() are passing __WQ_LEGACY flag using alloc_workqueue() > interface. Therefore, __WQ_LEGACY flag is no longer a meaningful indicator of > "internal: create*_workqueue()". Description for __WQ_LEGACY flag needs an > update. ... > Given that the legacy create_workqueue() interface always implied WQ_MEM_RECLAIM flag, > > maybe it is better to make alloc_workqueue() interface WQ_MEM_RECLAIM by default. That actually is pretty expensive when added up, which is why we went for the shared worker pool model in the first place. > That is, obsolete WQ_MEM_RECLAIM flag and __WQ_LEGACY flag, and introduce a new flag > (e.g. WQ_MAY_SHARE_WORKER) which is passed to alloc_workqueue() interface only when > it is absolutely confident that this WQ never participates in memory reclaim path and > never participates in flush_workqueue()/flush_work() operation. No, just fix the abusers. There are four abusers in the kernel and they aren't difficult to fix. Thanks. -- tejun
