From: Andrew Morton <akpm@linux-foundation.org>
To: Chen Wandun <chenwandun@huawei.com>
Cc: <hugh@veritas.com>, <linux-mm@kvack.org>,
<linux-kernel@vger.kernel.org>, <wangkefeng.wang@huawei.com>,
<sunnanyong@huawei.com>, <xialonglong1@huawei.com>,
Huang Ying <ying.huang@intel.com>
Subject: Re: [RFC PATCH] swapfile: fix soft lockup in scan_swap_map_slots
Date: Fri, 18 Nov 2022 13:27:41 -0800 [thread overview]
Message-ID: <20221118132741.aaf6f9081b5a1018cc9a5402@linux-foundation.org> (raw)
In-Reply-To: <20221118133850.3360369-1-chenwandun@huawei.com>
On Fri, 18 Nov 2022 21:38:50 +0800 Chen Wandun <chenwandun@huawei.com> wrote:
> A soft lockup occur in scan free swap slot by constructing
> huge memory pressure.
> The test scenario is: 64 CPU cores, 64GB memory, and 28
> zram devices, the disksize of each zram device is 50MB.
>
> LATENCY_LIMIT is used to prevent soft lockup in function
> scan_swap_map_slots, but the real loop number would more
> than LATENCY_LIMIT because of "goto checks and goto scan"
> repeatly without decrease of latency limit.
>
> In order to fix it, move decrease latency_ration code in advance.
>
> There is also a suspicious place that will cause soft lockup in
> function get_swap_pages, in this function, the "goto start_over"
> may result in continuous scanning of swap partition, if there is
> no cond_sched in scan_swap_map_slots, it would cause soft lockup
> (I am not sure about this).
>
> ...
>
Looks sensible.
> --- a/mm/swapfile.c
> +++ b/mm/swapfile.c
> @@ -972,23 +972,23 @@ static int scan_swap_map_slots(struct swap_info_struct *si,
> scan:
> spin_unlock(&si->lock);
> while (++offset <= READ_ONCE(si->highest_bit)) {
> - if (swap_offset_available_and_locked(si, offset))
> - goto checks;
> if (unlikely(--latency_ration < 0)) {
> cond_resched();
> latency_ration = LATENCY_LIMIT;
> scanned_many = true;
> }
> + if (swap_offset_available_and_locked(si, offset))
> + goto checks;
> }
> offset = si->lowest_bit;
> while (offset < scan_base) {
> - if (swap_offset_available_and_locked(si, offset))
> - goto checks;
> if (unlikely(--latency_ration < 0)) {
> cond_resched();
> latency_ration = LATENCY_LIMIT;
> scanned_many = true;
> }
> + if (swap_offset_available_and_locked(si, offset))
> + goto checks;
> offset++;
> }
> spin_lock(&si->lock);
But this does somewhat alter the `scanned_many' logic. We'll now set
'scanned_many` earlier. What are the effects of this?
The ed43af10975eef7e changelog outlines tests which could be performed
to ensure we aren't regressing from this.
next prev parent reply other threads:[~2022-11-18 21:27 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-11-18 13:38 Chen Wandun
2022-11-18 21:27 ` Andrew Morton [this message]
2022-11-21 1:53 ` Huang, Ying
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=20221118132741.aaf6f9081b5a1018cc9a5402@linux-foundation.org \
--to=akpm@linux-foundation.org \
--cc=chenwandun@huawei.com \
--cc=hugh@veritas.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=sunnanyong@huawei.com \
--cc=wangkefeng.wang@huawei.com \
--cc=xialonglong1@huawei.com \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox