From: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
To: "Huang, Ying" <ying.huang@intel.com>
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:45:02 +0900 [thread overview]
Message-ID: <dc660fa4-1d0d-75e1-5496-36bef9117469@I-love.SAKURA.ne.jp> (raw)
In-Reply-To: <871qj7zz8z.fsf@yhuang6-desk2.ccr.corp.intel.com>
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.
next prev parent reply other threads:[~2023-05-23 0:45 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-05-20 8:26 [syzbot] [kernel?] possible deadlock in scheduler_tick (2) syzbot
2023-05-20 11:02 ` 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 [this message]
2023-05-23 1:10 ` Huang, Ying
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=dc660fa4-1d0d-75e1-5496-36bef9117469@I-love.SAKURA.ne.jp \
--to=penguin-kernel@i-love.sakura.ne.jp \
--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=ryabinin.a.a@gmail.com \
--cc=syzbot+ece2915262061d6e0ac1@syzkaller.appspotmail.com \
--cc=syzkaller-bugs@googlegroups.com \
--cc=vbabka@suse.cz \
--cc=ying.huang@intel.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.