I'm not opposing to have fundamental solutions. As you know the fundamental solution will need many years to complete, I'm asking for interim workaround which we can use now. Michal Hocko wrote: > The problem, as I see it, is that such a change cannot be pushed to > Linus tree without extensive testing because there are thousands of code > paths which never got exercised. We have basically two options here. Your options are based on your proposal. We can have different options based on Johannes's and my proposal. > Either have a non-upstream patch (e.g. sitting in mmotm and linux-next) > and have developers to do their testing. This will surely help to > catch a lot of fallouts and fix them right away. But we will miss those > who are using Linus based trees and would be willing to help to test > in their loads which we never dreamed of. > The other option would be pushing an experimental code to the Linus > tree (and distribution kernels) and allow people to turn it on to help > testing. The third option is to purge majority of code paths which never got exercised, by replacing kmalloc() with kmalloc_nofail() where amount of requested size is known to be <= PAGE_SIZE bytes. The third option becomes possible if we "allow triggering the OOM killer for both __GFP_FS allocations and !__GFP_FS allocations" and "introduce the OOM-killer timeout" so that OOM-deadlock which we are already observing can be handled. -- 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>