From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 7DBB6C433F5 for ; Mon, 20 Dec 2021 08:50:39 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id BDFF26B0071; Mon, 20 Dec 2021 03:50:38 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id B8DD86B0073; Mon, 20 Dec 2021 03:50:38 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A56376B0074; Mon, 20 Dec 2021 03:50:38 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0116.hostedemail.com [216.40.44.116]) by kanga.kvack.org (Postfix) with ESMTP id 971F16B0071 for ; Mon, 20 Dec 2021 03:50:38 -0500 (EST) Received: from smtpin23.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id 544F38249980 for ; Mon, 20 Dec 2021 08:50:38 +0000 (UTC) X-FDA: 78937551756.23.783CEED Received: from mail-pl1-f182.google.com (mail-pl1-f182.google.com [209.85.214.182]) by imf23.hostedemail.com (Postfix) with ESMTP id C7C3E14002D for ; Mon, 20 Dec 2021 08:50:31 +0000 (UTC) Received: by mail-pl1-f182.google.com with SMTP id o14so7540211plg.5 for ; Mon, 20 Dec 2021 00:50:37 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=p9+kIzX2zRZpA12q8ZaVo/FiqIwT3gc0hricozgRWRo=; b=GuiwnYF+uczdG5w7pEi7LWyexsfb0KGZntzVPLer3j6cikphRgF7C7Ay4adEWYd0m1 fYSh1c5kT9+xNGb1EY1193OUIk6gvKT9iWsj//bU0UT+B7tbcpBpfZCrVmUZIW7AjQun F89SUZ5bbtTzMzOqUl+DQPKli6DhtQEy937U2Dos8Jo4KMv4gx2PE9EbytxQi8tzlQqk SR+Ep1xcNvCbUtn6f6BhrSmwMEOBhhcuwjQSqnydgbeNlW8IUG3Vzb06EnSs4mWwBNsq 1sjqIh2clxGBqm9swqvWkbZOorePF4rxg26ZvYwGhqpPANdGrJhjSd1V4l/Pplw20onU bqag== X-Gm-Message-State: AOAM530y/G+O5jV3nzQQopxnd11rvmaz/YUayRDt7vzlgB+b33myVm/6 9UDS3Lrek8piiqquwX+wVnY= X-Google-Smtp-Source: ABdhPJzwxevOLrWBPHDrZoK+aCc3OpGXBGdw/ATREwLLVmCo+mHv7H/QAy04KcXUwjmMIZPBd4u0Lg== X-Received: by 2002:a17:903:1246:b0:148:a3e3:c0d with SMTP id u6-20020a170903124600b00148a3e30c0dmr15860025plh.108.1639990236992; Mon, 20 Dec 2021 00:50:36 -0800 (PST) Received: from sultan-box.localdomain (static-198-54-129-52.cust.tzulo.com. [198.54.129.52]) by smtp.gmail.com with ESMTPSA id nu18sm2614968pjb.15.2021.12.20.00.50.35 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 20 Dec 2021 00:50:36 -0800 (PST) Date: Mon, 20 Dec 2021 00:50:33 -0800 From: Sultan Alsawaf To: Mel Gorman Cc: Alexey Avramov , linux-mm@kvack.org, linux-kernel@vger.kernel.org, mhocko@suse.com, vbabka@suse.cz, neilb@suse.de, akpm@linux-foundation.org, corbet@lwn.net, riel@surriel.com, hannes@cmpxchg.org, david@fromorbit.com, willy@infradead.org, hdanton@sina.com, penguin-kernel@i-love.sakura.ne.jp, oleksandr@natalenko.name, kernel@xanmod.org, michael@michaellarabel.com, aros@gmx.com, hakavlad@gmail.com Subject: Re: mm: 5.16 regression: reclaim_throttle leads to stall in near-OOM conditions Message-ID: References: <20211124011954.7cab9bb4@mail.inbox.lv> <20211124103550.GE3366@techsingularity.net> <20211124195449.33f31e7f@mail.inbox.lv> <20211124115007.GG3366@techsingularity.net> <20211124214443.5c179d34@mail.inbox.lv> <20211124143303.GH3366@techsingularity.net> <20211127010631.4e33a432@mail.inbox.lv> <20211126162416.GK3366@techsingularity.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20211126162416.GK3366@techsingularity.net> X-Stat-Signature: wftrrebbpqkmow9cga3m7j7mizesfufi X-Rspamd-Server: rspam01 X-Rspamd-Queue-Id: C7C3E14002D Authentication-Results: imf23.hostedemail.com; dkim=none; spf=pass (imf23.hostedemail.com: domain of sultan.kerneltoast@gmail.com designates 209.85.214.182 as permitted sender) smtp.mailfrom=sultan.kerneltoast@gmail.com; dmarc=none X-HE-Tag: 1639990231-177338 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: 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 [1] 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. [1] https://lore.kernel.org/linux-mm/20200219182522.1960-1-sultan@kerneltoast.com/ Sultan