On Fri 20-02-15 08:43:56, Dave Chinner wrote: > On Thu, Feb 19, 2015 at 01:29:14PM +0100, Michal Hocko wrote: > > On Thu 19-02-15 06:01:24, Johannes Weiner wrote: > > [...] > > > Preferrably, we'd get rid of all nofail allocations and replace them > > > with preallocated reserves. But this is not going to happen anytime > > > soon, so what other option do we have than resolving this on the OOM > > > killer side? > > > > As I've mentioned in other email, we might give GFP_NOFAIL allocator > > access to memory reserves (by giving it __GFP_HIGH). > > Won't work when you have thousands of concurrent transactions > running in XFS and they are all doing GFP_NOFAIL allocations. Is there any bound on how many transactions can run at the same time? > That's why I suggested the per-transaction reserve pool - we can use > that I am still not sure what you mean by reserve pool (API wise). How does it differ from pre-allocating memory before the "may not fail context"? Could you elaborate on it, please? > to throttle the number of concurent contexts demanding memory for > forwards progress, just the same was we throttle the number of > concurrent processes based on maximum log space requirements of the > transactions and the amount of unreserved log space available. > > No log space, transaction reservations waits on an ordered queue for > space to become available. No memory available, transaction > reservation waits on an ordered queue for memory to become > available. > > Cheers, > > Dave. > -- > Dave Chinner > david@xxxxxxxxxxxxx -- Michal Hocko SUSE Labs _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
