From: "Huang, Ying" <ying.huang@intel.com>
To: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Cc: syzbot <syzbot+ece2915262061d6e0ac1@syzkaller.appspotmail.com>,
<syzkaller-bugs@googlegroups.com>,
Mel Gorman <mgorman@techsingularity.net>,
Vlastimil Babka <vbabka@suse.cz>,
Andrew Morton <akpm@linux-foundation.org>,
Alexander Potapenko <glider@google.com>,
Andrey Konovalov <andreyknvl@gmail.com>,
Dmitry Vyukov <dvyukov@google.com>,
Andrey Ryabinin <ryabinin.a.a@gmail.com>,
kasan-dev <kasan-dev@googlegroups.com>,
linux-mm <linux-mm@kvack.org>,
Johannes Weiner <hannes@cmpxchg.org>,
Michal Hocko <mhocko@kernel.org>
Subject: Re: [PATCH] lib/stackdepot: stackdepot: don't use __GFP_KSWAPD_RECLAIM from __stack_depot_save() if atomic context
Date: Tue, 23 May 2023 09:10:20 +0800 [thread overview]
Message-ID: <87fs7nyhs3.fsf@yhuang6-desk2.ccr.corp.intel.com> (raw)
In-Reply-To: <dc660fa4-1d0d-75e1-5496-36bef9117469@I-love.SAKURA.ne.jp> (Tetsuo Handa's message of "Tue, 23 May 2023 09:45:02 +0900")
Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> 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
next prev parent reply other threads:[~2023-05-23 1:11 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <000000000000cef3a005fc1bcc80@google.com>
2023-05-20 11:02 ` [syzbot] [kernel?] possible deadlock in scheduler_tick (2) Tetsuo Handa
2023-05-20 11:33 ` [PATCH] lib/stackdepot: stackdepot: don't use __GFP_KSWAPD_RECLAIM from __stack_depot_save() if atomic context Tetsuo Handa
2023-05-20 13:14 ` Tetsuo Handa
2023-05-20 22:44 ` Tetsuo Handa
2023-05-22 2:13 ` Huang, Ying
2023-05-22 2:47 ` Tetsuo Handa
2023-05-22 3:07 ` Huang, Ying
2023-05-22 11:33 ` Tetsuo Handa
2023-05-23 0:07 ` Huang, Ying
2023-05-23 0:45 ` Tetsuo Handa
2023-05-23 1:10 ` Huang, Ying [this message]
2023-05-24 12:09 ` Michal Hocko
2023-05-27 15:25 ` [PATCH] kasan,kmsan: remove __GFP_KSWAPD_RECLAIM usage from kasan/kmsan Tetsuo Handa
2023-05-29 1:07 ` Huang, Ying
2023-05-31 13:31 ` Alexander Potapenko
2023-06-09 22:31 ` Andrew Morton
[not found] ` <19d6c965-a9cf-16a5-6537-a02823d67c0a@I-love.SAKURA.ne.jp>
2023-06-12 1:30 ` [PATCH v3] lib/stackdepot: fix gfp flags manipulation in __stack_depot_save() Huang, Ying
2023-06-21 12:56 ` Alexander Potapenko
2023-06-21 14:07 ` Tetsuo Handa
2023-06-21 14:42 ` Alexander Potapenko
2023-06-21 14:54 ` Tetsuo Handa
2023-06-21 15:37 ` [PATCH] kasan,kmsan: remove __GFP_KSWAPD_RECLAIM usage from kasan/kmsan Alexander Potapenko
2023-05-27 21:01 ` [syzbot] [ntfs3?] possible deadlock in scheduler_tick (2) syzbot
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87fs7nyhs3.fsf@yhuang6-desk2.ccr.corp.intel.com \
--to=ying.huang@intel.com \
--cc=akpm@linux-foundation.org \
--cc=andreyknvl@gmail.com \
--cc=dvyukov@google.com \
--cc=glider@google.com \
--cc=hannes@cmpxchg.org \
--cc=kasan-dev@googlegroups.com \
--cc=linux-mm@kvack.org \
--cc=mgorman@techsingularity.net \
--cc=mhocko@kernel.org \
--cc=penguin-kernel@I-love.SAKURA.ne.jp \
--cc=ryabinin.a.a@gmail.com \
--cc=syzbot+ece2915262061d6e0ac1@syzkaller.appspotmail.com \
--cc=syzkaller-bugs@googlegroups.com \
--cc=vbabka@suse.cz \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox