On Mon, Mar 02, 2015 at 04:18:32PM +0100, Michal Hocko wrote: > The idea is sound. But I am pretty sure we will find many corner > cases. E.g. what if the mere reservation attempt causes the system > to go OOM and trigger the OOM killer? Doctor, doctor, it hurts when I do that.... So don't trigger the OOM killer. We can let the caller decide whether the reservation request should block or return ENOMEM, but the whole point of the reservation request idea is that this happens *before* we've taken any mutexes, so blocking won't prevent forward progress. The file system could send down a different flag if we are doing writebacks for page cleaning purposes, in which case the reservation request would be a "just a heads up, we *will* be needing this much memory, but this is not something where we can block or return ENOMEM, so please give us the highest priority for using the free reserves". > I think the idea is good! It will just be quite tricky to get there > without causing more problems than those being solved. The biggest > question mark so far seems to be the reservation size estimation. If > it is hard for any caller to know the size beforehand (which would > be really close to the actually used size) then the whole complexity > in the code sounds like an overkill and asking administrator to tune > min_free_kbytes seems a better fit (we would still have to teach the > allocator to access reserves when really necessary) because the system > would behave more predictably (although some memory would be wasted). If we do need to teach the allocator to access reserves when really necessary, don't we have that already via GFP_NOIO/GFP_NOFS and GFP_NOFAIL? If the goal is do something more fine-grained, unfortunately at least for the short-term we'll need to preserve the existing behaviour and issue warnings until the file system starts adding GFP_NOFAIL to those memory allocations where previously, GFP_NOFS was effectively guaranteeing that failures would almostt never happen. I know at least one place discovered with recent change (and revert) where I'll be fixing ext4, but I suspect it won't be the only one, especially in the block device drivers. - Ted _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
