>> We don't know how many callers will pass __GFP_NOFAIL. But if 1000 >> threads are doing the same operation which requires __GFP_NOFAIL >> allocation with a lock held, wouldn't memory reserves deplete? > > We shouldn't have an unbounded number of GFP_NOFAIL allocations at the > same time. This would be even more broken. If a load is known to use > such allocations excessively then the administrator can enlarge the > memory reserves. > >> This heuristic can't continue if memory reserves depleted or >> continuous pages of requested order cannot be found. > > Once memory reserves are depleted we are screwed anyway and we might > panic. This discussion reminds me of a situation I've seen somewhat regularly, which I have described here: http://oss.sgi.com/pipermail/xfs/2014-April/035793.html I've actually seen it more often on another box with OpenVZ and VirtualBox installed, where it would almost always happen during startup of a VirtualBox guest machine. This other machine is also running XFS. I blamed it on OpenVZ or VirtualBox originally, but having seen the same thing happen on the other machine with neither of them, the next candidate for taking blame is XFS. Is this behavior something that can be attributed to these memory allocation retry loops? -- 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>