Reduced to only linux-mm. > From: Johannes Weiner <hannes@xxxxxxxxxxx> > > GFP_NOFS allocations are not allowed to invoke the OOM killer since > their reclaim abilities are severely diminished. However, without the > OOM killer available there is no hope of progress once the reclaimable > pages have been exhausted. Excuse me, but I still cannot understand. Why are !__GFP_FS allocations considered as "their reclaim abilities are severely diminished"? It seems to me that not only GFP_NOFS allocation requests but also almost all types of memory allocation requests do not include __GFP_NO_KSWAPD flag. Therefore, while a thread which called __alloc_pages_slowpath(GFP_NOFS) cannot reclaim FS memory, I assume that kswapd kernel threads which are woken up by the thread via wakeup_kswapd() via wake_all_kswapds() can reclaim FS memory by calling balance_pgdat(). Is this assumption correct? If the assumption is correct, when kswapd kernel threads returned from balance_pgdat() or got stuck inside reclaiming functions (e.g. blocked at mutex_lock() inside slab's shrinker functions), I think that the thread which called __alloc_pages_slowpath(GFP_NOFS) has reclaimed FS memory as if the thread called __alloc_pages_slowpath(GFP_KERNEL), and therefore the thread qualifies calling out_of_memory() as with __GFP_FS allocations. > > Don't risk hanging these allocations. Leave it to the allocation site > to implement the fallback policy for failing allocations. Are there memory pages which kswapd kernel threads cannot reclaim but __alloc_pages_slowpath(GFP_KERNEL) allocations can reclaim when __alloc_pages_slowpath(GFP_NOFS) allocations are hanging? -- 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>