Hi, Am 26.01.2018 um 16:05 schrieb Tejun Heo: > Hello, > > On Fri, Jan 26, 2018 at 09:08:02AM +0100, Johannes Berg wrote: >> Not that you mention it ... Honestly though, wifi connections break all >> the time, so not sure you'd really want that. But anyway, that's what >> we have. > I'd be a lot happier to remove WQ_MEM_RECLAIM from wireless drivers > too, and glancing the code, it looked like there already are so many > holes that whether having that flag or not shouldn't matter all that > much. It was just difficult for me to make a case for removing it > preemptively. If you're up for it, please be my guest. I think, it is quite clear, why this error is produced, since in memory reclaim, we should not synchronously flush unimportant work queues. I think there could be valid use cases to have work queues with that flag in wireless drivers, if the are used carefully. Therefore I suggest a hint in the work queue documentation like:
"Check whether work_items on WQ_MEM_RECLAIM wq may actively delay memory reclaim with network timeouts and check whether other work queues without WQ_MEM_RECLAIM may be flushed within work_items of the queue, as this will prioritize non-reclaiming work_items on the flushed queue the same level as reclaiming work_items". At least this can help for future usage, as it could have avoided my error :-D > Thanks. > -- M.Sc. Benjamin Beichler Universität Rostock, Fakultät für Informatik und Elektrotechnik Institut für Angewandte Mikroelektronik und Datentechnik University of Rostock, Department of CS and EE Institute of Applied Microelectronics and CE Richard-Wagner-Straße 31 18119 Rostock Deutschland/Germany phone: +49 (0) 381 498 - 7278 email: benjamin.beich...@uni-rostock.de www: http://www.imd.uni-rostock.de/
smime.p7s
Description: S/MIME Cryptographic Signature
