Hello, Prateek. On Mon, Jan 15, 2018 at 05:32:18PM +0530, Prateek Sood wrote: > My understanding of WQ_MEM_RECLAIM was that it needs to be used for > cases where memory pressure could cause deadlocks. Yes, that is the primary role; however, there are a couple places where we need it to isolate a low level subsystem's forward progress from the dependencies of the dynanic worker pool management. > In this case it does not seem to be a memory pressure issue. > Overloading WQ_MEM_RECLAIM usage for solution to another problem > is the correct approach? In general, we don't face this issue but for things like RCU, I do believe this is the right approach. The name of the flag is a bit of misnomer for those cases as it only describes one of the dependencies of worker pool management. I don't think it's an actual problem given that vast majority of the usages are protecting against memory dependency. > This scenario can be resolved by using WQ_MEM_RECLAIM and a separate > workqueue for rcu. But there seems to be a possibility in future if > any cpu hotplug callbacks use other predefined workqueues which do not > have WQ_MEM_RECLAIM option. We want to isolate from this sort of dependencies anyway, especially how widely and deeply we depend on RCU these days. Maybe we will develop a justified case in the future but at least up until now every case around this issue seems to be something to be fixed on their own. Thanks. -- tejun -- To unsubscribe from this list: send the line "unsubscribe cgroups" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
