On Wed, 9 Jan 2013, Glauber Costa wrote: > I will certainly look into that. But I still fear that regardless of > what we do here, the logic is still "retry the whole thing again". We > already know there is no free page, and without inspecting the internals > of the allocator it is hard to know where to start looking - therefore, > we need to retry from the start. The slow paths functions in the allocator can performa the retry of "the whole thing". slab's fallback alloc does precisely that. What you need to do there is to just go back to the retry: label if the attempt to grow the slab fails. slub's __slab_alloc() can use a similar approach by looping back to the redo: label. Either one is trivial to implement. > If it fails again, we will recurse to the same oom state. This means we > need to keep track of the state, at least, in which retry we are. If I > can keep it local, fine, I will argue no further. But if this state > needs to spread throughout the other paths, I think we have a lot more > to lose. Adding another state variable is not that intrusive in fallback_alloc or __slab_alloc. Alternatively we could extract the functionality to check the current queues from the allocator and call them twice from the slow paths. -- 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>