On Tue, Mar 31, 2020 at 05:34:50PM +0200, Michal Hocko wrote: > On Tue 31-03-20 10:58:06, Joel Fernandes wrote: > [...] > > > diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c > > > index 4be763355c9fb..965deefffdd58 100644 > > > --- a/kernel/rcu/tree.c > > > +++ b/kernel/rcu/tree.c > > > @@ -3149,7 +3149,7 @@ static inline struct rcu_head *attach_rcu_head_to_object(void *obj) > > > > > > if (!ptr) > > > ptr = kmalloc(sizeof(unsigned long *) + > > > - sizeof(struct rcu_head), GFP_ATOMIC | __GFP_NOWARN); > > > + sizeof(struct rcu_head), GFP_MEMALLOC); > > > > Just to add, the main requirements here are: > > 1. Allocation should be bounded in time. > > 2. Allocation should try hard (possibly tapping into reserves) > > 3. Sleeping is Ok but should not affect the time bound. > > > __GFP_ATOMIC | __GFP_HIGH is the way to get an additional access to > memory reserves regarless of the sleeping status. > > Using __GFP_MEMALLOC is quite dangerous because it can deplete _all_ the > memory. What does prevent the above code path to do that? Can you suggest what prevents other users of GFP_MEMALLOC from doing that also? That's the whole point of having a reserve, in normal usage no one will use it, but some times you need to use it. Keep in mind this is not a common case in this code here, this is triggered only if earlier allocation attempts failed. Only *then* we try with GFP_MEMALLOC with promises to free additional memory soon. > If a partial access to reserves is sufficient then why the existing > modifiers (mentioned above are not sufficient? The point with using GFP_MEMALLOC is it is useful for situations where you are about to free memory and needed some memory temporarily, to free that. It depletes it a bit temporarily to free even more. Is that not the point of PF_MEMALLOC? * %__GFP_MEMALLOC allows access to all memory. This should only be used when * the caller guarantees the allocation will allow more memory to be freed * very shortly e.g. process exiting or swapping. Users either should * be the MM or co-ordinating closely with the VM (e.g. swap over NFS). I was just recommending usage of this flag here because it fits the requirement of allocating some memory to free some memory. I am also Ok with GFP_ATOMIC with the GFP_NOWARN removed, if you are Ok with that. thanks, - Joel
