From: Dongyun Liu <dongyun.liu3@gmail.com>
To: Sergey Senozhatsky <senozhatsky@chromium.org>
Cc: minchan@kernel.org, axboe@kernel.dk,
linux-kernel@vger.kernel.org, linux-block@vger.kernel.org,
lincheng.yang@transsion.com, jiajun.ling@transsion.com,
ldys2014@foxmail.com, Dongyun Liu <dongyun.liu@transsion.com>
Subject: Re: [PATCH] zram: Using GFP_ATOMIC instead of GFP_KERNEL to allocate bitmap memory in backing_dev_store
Date: Sat, 2 Dec 2023 23:50:28 +0800 [thread overview]
Message-ID: <b49d6a29-e3a3-4b6b-8892-8ded319b2619@gmail.com> (raw)
In-Reply-To: <20231201153956.GB404241@google.com>
On 2023/12/1 23:39, Sergey Senozhatsky wrote:
> On (23/11/30 23:20), Dongyun Liu wrote:
>> INFO: task init:331 blocked for more than 120 seconds. "echo 0 >
>> /proc/sys/kernel/hung_task_timeout_secs" disables this message.
>> task:init state:D stack: 0 pid: 1 ppid: 0 flags:0x04000000
>> Call trace:
>> __switch_to+0x244/0x4e4
>> __schedule+0x5bc/0xc48
>> schedule+0x80/0x164
>> rwsem_down_read_slowpath+0x4fc/0xf9c
>> __down_read+0x140/0x188
>> down_read+0x14/0x24
>> try_wakeup_wbd_thread+0x78/0x1ec [zram]
>> __zram_bvec_write+0x720/0x878 [zram]
>> zram_bvec_rw+0xa8/0x234 [zram]
>> zram_submit_bio+0x16c/0x268 [zram]
>> submit_bio_noacct+0x128/0x3c8
>> submit_bio+0x1cc/0x3d0
>> __swap_writepage+0x5c4/0xd4c
>> swap_writepage+0x130/0x158
>> pageout+0x1f4/0x478
>> shrink_page_list+0x9b4/0x1eb8
>> shrink_inactive_list+0x2f4/0xaa8
>> shrink_lruvec+0x184/0x340
>> shrink_node_memcgs+0x84/0x3a0
>> shrink_node+0x2c4/0x6c4
>> shrink_zones+0x16c/0x29c
>> do_try_to_free_pages+0xe4/0x2b4
>> try_to_free_pages+0x388/0x7b4
>> __alloc_pages_direct_reclaim+0x88/0x278
>> __alloc_pages_slowpath+0x4ec/0xf6c
>> __alloc_pages_nodemask+0x1f4/0x3dc
>> kmalloc_order+0x54/0x338
>> kmalloc_order_trace+0x34/0x1bc
>> __kmalloc+0x5e8/0x9c0
>> kvmalloc_node+0xa8/0x264
>> backing_dev_store+0x1a4/0x818 [zram]
>> dev_attr_store+0x38/0x8c
>> sysfs_kf_write+0x64/0xc4
>
> Hmm, I'm not really following this backtrace. Backing device
> configuration is only possible on un-initialized zram device.
> If it's uninitialized, then why is it being used for swapout
> later in the call stack?
Uh, at this moment, zram has finished initializing and is
working. The backing device is an optional zram-based feature.
I think it can be created later.
next prev parent reply other threads:[~2023-12-02 15:50 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-11-30 15:20 Dongyun Liu
2023-11-30 15:37 ` Jens Axboe
2023-12-01 6:51 ` Dongyun Liu
2023-12-01 14:19 ` Jens Axboe
2023-12-01 15:28 ` Sergey Senozhatsky
2023-12-02 13:54 ` Dongyun Liu
2023-12-01 15:39 ` Sergey Senozhatsky
2023-12-02 15:50 ` Dongyun Liu [this message]
2023-12-03 1:23 ` Sergey Senozhatsky
2023-12-03 14:45 ` Dongyun Liu
2023-12-01 18:41 ` Minchan Kim
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=b49d6a29-e3a3-4b6b-8892-8ded319b2619@gmail.com \
--to=dongyun.liu3@gmail.com \
--cc=axboe@kernel.dk \
--cc=dongyun.liu@transsion.com \
--cc=jiajun.ling@transsion.com \
--cc=ldys2014@foxmail.com \
--cc=lincheng.yang@transsion.com \
--cc=linux-block@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=minchan@kernel.org \
--cc=senozhatsky@chromium.org \
/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
all inboxes | Powered by JetHome®