From: Sultan Alsawaf <firstname.lastname@example.org> To: Mel Gorman <email@example.com> Cc: Alexey Avramov <firstname.lastname@example.org>, email@example.com, firstname.lastname@example.org, email@example.com, firstname.lastname@example.org, email@example.com, firstname.lastname@example.org, email@example.com, firstname.lastname@example.org, email@example.com, firstname.lastname@example.org, email@example.com, firstname.lastname@example.org, email@example.com, firstname.lastname@example.org, email@example.com, firstname.lastname@example.org, email@example.com, firstname.lastname@example.org Subject: Re: mm: 5.16 regression: reclaim_throttle leads to stall in near-OOM conditions Date: Mon, 20 Dec 2021 00:50:33 -0800 [thread overview] Message-ID: <YcBD2dQEaBkwz/0H@sultan-box.localdomain> (raw) In-Reply-To: <20211126162416.GK3366@techsingularity.net> On Fri, Nov 26, 2021 at 04:24:16PM +0000, Mel Gorman wrote: > It's somewhat expected. If the system is able to make some sort of > progress and kswapd is active, it'll throttle until progress is > impossible. It'll be somewhat variable how long it can keep making > progress be it discarding page cache or writing to swap but it'll only > OOM when the system is truly OOM. > > Might be worth trying the patch below on top. It will delay throttling > for longer with the caveat that CPU usage due to reclaim when very low > on memory may be excessive. Mel, Perhaps my old submission  could be helpful here? I could send a refreshed version if you're interested. Using wall time to throttle reclaim seems quite catastrophic IMO, given the inherent assumptions it makes about the running system's performance characteristics and its workloads. My patch tackles the issue from the opposite direction: rather than throttling when there's no reclaim progress to be made, my approach stops kswapd early when there is no longer any need for reclaim, which conveniently doesn't require any sort of tunable or heuristic since kswapd can just be immediately woken up again right after if needed. Looking back, it seems your chief complaint was that my patch may stop kswapd before it could reclaim up to the high watermark, which could thereby introduce stalls; however, I've never run into any such issue in my testing, and neither have the several people who use my patch under a wide range of setups.  https://email@example.com/ Sultan
next prev parent reply other threads:[~2021-12-20 8:50 UTC|newest] Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-11-23 16:19 Alexey Avramov 2021-11-24 7:40 ` Thorsten Leemhuis 2021-11-24 10:35 ` Mel Gorman 2021-11-24 10:54 ` Alexey Avramov 2021-11-24 11:50 ` Mel Gorman 2021-11-24 12:03 ` Alexey Avramov 2021-11-24 12:44 ` Alexey Avramov 2021-11-24 14:33 ` Mel Gorman 2021-11-26 16:06 ` Alexey Avramov 2021-11-26 16:24 ` Mel Gorman 2021-12-20 8:50 ` Sultan Alsawaf [this message] 2021-11-27 19:37 ` Alexey Avramov
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=YcBD2dQEaBkwz/0H@sultan-box.localdomain \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --subject='Re: mm: 5.16 regression: reclaim_throttle leads to stall in near-OOM conditions' \ /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
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).