On 12/13/22 07:41, Michal Hocko wrote: > This makes sense but I suspect that this wasn't intended also for > memcg triggered reclaim. This would mean that a memory pressure in one > hierarchy could trigger paging out pages of a different hierarchy if the > demotion target is close to full. > > I haven't really checked at the current kswapd wake up checks but I > suspect that kswapd would back off in most cases so this shouldn't > really cause any big problems. But I guess it would be better to simply > not wake kswapd up for the memcg reclaim. What do you think? You're right that this wasn't really considering memcg-based reclaim. The entire original idea was that demotion allocations should fail fast, but it would be nice if they could kick kswapd so they would *eventually* succeed and just just fail fast forever. Before we go trying to patch anything, I'd be really interested what it does in practice. How much does it actually wake up kswapd? Does kswapd cause any collateral damage? I don't have any fundamental objections to the patch, though.
