Tetsuo Handa <penguin-kernel@xxxxxxxxxxxxxxxxxxx> writes: > 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". Got it. > 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. Personally, I prefer to wake up kswapd ASAP. And fix the deadlock if possible. Best Regards, Huang, Ying
