On 2023/05/22 11:13, Huang, Ying wrote: >> Any atomic allocation used by KASAN needs to drop __GFP_KSWAPD_RECLAIM bit. >> Where do we want to drop this bit (in the caller side, or in the callee side)? > > Yes. I think we should fix the KASAN. Maybe define a new GFP_XXX > (instead of GFP_ATOMIC) for debug code? The debug code may be called at > almost arbitrary places, and wakeup_kswap() isn't safe to be called in > some situations. What do you think about removing __GFP_KSWAPD_RECLAIM from GFP_ATOMIC and GFP_NOWAIT? Recent reports indicate that atomic allocations (GFP_ATOMIC and GFP_NOWAIT) are not safe enough to think "atomic". They just don't do direct reclaim, but they do take spinlocks. Removing __GFP_KSWAPD_RECLAIM from GFP_ATOMIC and GFP_NOWAIT simplifies locking dependency and reduces latency of atomic allocations (which is important when called from "atomic" context). I consider that memory allocations which do not do direct reclaim should be geared towards less locking dependency. In general, GFP_ATOMIC or GFP_NOWAIT users will not allocate many pages. It is likely that somebody else tries to allocate memory using __GFP_DIRECT_RECLAIM right after GFP_ATOMIC or GFP_NOWAIT allocations. We unlikely need to wake kswapd upon GFP_ATOMIC or GFP_NOWAIT allocations. If some GFP_ATOMIC or GFP_NOWAIT users need to allocate many pages, they can add __GFP_KSWAPD_RECLAIM explicitly; though allocating many pages using GFP_ATOMIC or GFP_NOWAIT is not recommended from the beginning...
