On 2023/05/23 9:07, Huang, Ying wrote: >>> Except debug code, where do you find locking issues for waking up kswapd? >> >> I'm not aware of lockdep reports except debug code. >> >> But due to too many locking dependency, lockdep gives up tracking all dependency (e.g. >> >> https://syzkaller.appspot.com/bug?extid=8a249628ae32ea7de3a2 >> https://syzkaller.appspot.com/bug?extid=a70a6358abd2c3f9550f >> https://syzkaller.appspot.com/bug?extid=9bbbacfbf1e04d5221f7 >> https://syzkaller.appspot.com/bug?extid=b04c9ffbbd2f303d00d9 >> >> ). I want to reduce locking patterns where possible. pgdat->{kswapd,kcompactd}_wait.lock >> and zonelist_update_seq are candidates which need not to be held from interrupt context. > > Why is it not safe to wake up kswapd/kcompactd from interrupt context? I'm not saying it is not safe to wake up kswapd/kcompactd from interrupt context. Please notice that I'm using "need not" than "must not". Since total amount of RAM a Linux kernel can use had been increased over years, watermark gap between "kswapd should start background reclaim" and "current thread must start foreground reclaim" also increased. Then, randomly allocating small amount of pages from interrupt context (or atomic context) without waking up will not needlessly increase possibility of reaching "current thread must start foreground reclaim" watermark. Then, reducing locking dependency by not waking up becomes a gain. KASAN developers, I'm waiting for your response on How is the importance of memory allocation in __stack_depot_save() ? If allocation failure is welcome, maybe we should not trigger OOM killer by clearing __GFP_NORETRY when alloc_flags contained __GFP_FS ... part.
