On Mon 25-04-22 11:28:11, Kent Overstreet wrote: > On Mon, Apr 25, 2022 at 11:28:26AM +0200, Michal Hocko wrote: > > > > > Do you know if using memalloc_noreclaim_(save|restore) is sufficient for that, > > > or do we want GFP_ATOMIC? I'm already using GFP_ATOMIC for allocations when we > > > generate the report on slabs, since we're taking the slab mutex there. > > > > No it's not. You simply _cannot_ allocate from the oom context. > > Hmm, no, that can't be right. I've been using the patch set and it definitely > works, at least in my testing. Yes, the world will not fall down and it really depends on the workload what kind of effect this might have. > Do you mean to say that we shouldn't? Can you explain why? I have already touched on that but let me reiterate. Allocation context called from the oom path will have an unbound access to memory reserves. Those are a last resort emergency pools of memory that are not available normally and there are areas which really depend on them to make a further progress to release the memory pressure. Swap over NFS would be one such example. If some other code path messes with those reserves the swap IO path could fail with all sorts of fallouts. So to be really exact in my statement. You can allocate from the OOM context but it is _strongly_ discouraged unless there is no other way around that. I would even claim that the memory reclaim in general shouldn't rely on memory allocations (other than mempools). If an allocation is really necessary then an extra care has to prevent from complete memory depletion. -- Michal Hocko SUSE Labs
