Hello, Michal. On Fri, Oct 23, 2015 at 10:33:16AM +0200, Michal Hocko wrote: > Ohh, OK I can see wq_worker_sleeping now. I've missed your point in > other email, sorry about that. But now I am wondering whether this > is an intended behavior. The documentation says: This is. > WQ_MEM_RECLAIM > > All wq which might be used in the memory reclaim paths _MUST_ > have this flag set. The wq is guaranteed to have at least one > execution context regardless of memory pressure. > > Which doesn't seem to be true currently, right? Now I can see your patch It is true. > to introduce WQ_IMMEDIATE but I am wondering which WQ_MEM_RECLAIM users > could do without WQ_IMMEDIATE? I mean all current workers might be > looping in the page allocator and it seems possible that WQ_MEM_RECLAIM > work items might be waiting behind them so they cannot help to relieve > the memory pressure. This doesn't sound right to me. Or I am completely > confused and still fail to understand what is WQ_MEM_RECLAIM supposed to > be used for. It guarantees that there always is enough execution resource to execute a work item from that workqueue. The problem here is not lack of execution resource but concurrency management misunderstanding the situation. This also can be fixed by teaching concurrency management to be a bit smarter - e.g. if a work item is burning a lot of CPU cycles continuously or pool hasn't finished a work item over a certain amount of time, automatically ignore the in-flight work item for the purpose of concurrency management; however, this sort of inter-work item busy waits are so extremely rare and undesirable that I'm not sure the added complexity would be worthwhile. Thanks. -- tejun -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>