Received: by 2002:a05:6a10:206:0:0:0:0 with SMTP id 6csp2041566pxj; Wed, 19 May 2021 21:39:25 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxoWzD3WQ2zbFN3iCDnAczeLzWwvLvtgmy4iDOyLqE+Nv5Rhu536pob9F3pnTlhOohR+qvo X-Received: by 2002:a17:906:58cd:: with SMTP id e13mr2630259ejs.207.1621485565087; Wed, 19 May 2021 21:39:25 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1621485565; cv=none; d=google.com; s=arc-20160816; b=Wd0Km+Cbaa6szgcSgKPLh+tB6G2meAzVTpDh34PAB56hfqz44tw8/UUiRj+bctV5EV QDoMDtTIH2iR91TvpCitdGdUPTobY0Eu1nEE7xPSlyRIi0lPo1kfY1njT6LOVBpHYiT7 iUFgtTg81ciC5vdEhrctnLFQRlAlMVa5z+aPAFAhKsqAHy2IToXGyag9CmamCGBFptKI 1RbtNEhQeMK83IT161ULZtMTPC7LofeqFunTuCuA3mc3UdniKLSY8PwgDkLJplPVxmjH ZDLpxfQBEbu61GOOJ+97QHEDGZYGMOCMCyvveQcQNQ9Ip9pHCv84KYVWOE7xJ+lDbKJB dGLA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:subject:cc:to:from:date :dkim-signature; bh=liaVUPrLq5VpebxLfjIY+88q9SZEkXRERT+LL/M2W9Q=; b=R6BzbblRneF0BAHkTTyjgdexg+2iGzkImQFh12xy2phJUCn3/g+3/WjY2uEnHUFT8V F35S0xjz6o+0QVMwI/ok55raEjNHjncP/eq4xk0M4hOmkNkoPX6Ejo2RAzfh2X/6XPOs NA0bGt9DdfO3BrF7xdE8MXcUgZSRzSdIJ5I83R2lRo75z66lPGJ7lrXr2VA/QZiFNZFf xTJLNtpnafbaM1xOQNp9MTrbdFiuMAHBFJktsX0c4aFVfMUXbHkFVzl4qRcJnTJEdTWX hwfCldNPpHuA457NmOOtFDPcLiorNEr2xtQH/zPuUBUEw2wyX9CJi5b7P2mt4ajXipKF vw0w== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linux-foundation.org header.s=korg header.b=aUXuC9rc; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id q17si1209118edt.177.2021.05.19.21.39.01; Wed, 19 May 2021 21:39:25 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@linux-foundation.org header.s=korg header.b=aUXuC9rc; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229534AbhETEgR (ORCPT + 99 others); Thu, 20 May 2021 00:36:17 -0400 Received: from mail.kernel.org ([198.145.29.99]:33922 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229449AbhETEgR (ORCPT ); Thu, 20 May 2021 00:36:17 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id 9702D610CC; Thu, 20 May 2021 04:34:55 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linux-foundation.org; s=korg; t=1621485295; bh=KJiuXtdPBYbs0Q3wvWX1J2cBytAzfonsO3RA/+c2RmQ=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=aUXuC9rcdS09mfXi702zd909LrcM2sJxlqhkh62LPWAFl3GBtcQiu7pp6BRxPfaMb 0J5HoY6x6ZvxtTJ2KuWphAoO8ALGwPZhF3dLbSmaSWj9HUSYQ6mO/kwP0mseN9lKkF lrIpd4quwLYV9EI6XXVhMtJ9Xa1NtHPBjaC9M52U= Date: Wed, 19 May 2021 21:34:55 -0700 From: Andrew Morton To: Aaron Tomlin Cc: linux-mm@kvack.org, vbabka@suse.cz, mhocko@suse.com, willy@infradead.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v3] mm/page_alloc: bail out on fatal signal during reclaim/compaction retry attempt Message-Id: <20210519213455.97ff95f0124b4120787f8314@linux-foundation.org> In-Reply-To: <20210519201743.3260890-1-atomlin@redhat.com> References: <20210519201743.3260890-1-atomlin@redhat.com> X-Mailer: Sylpheed 3.5.1 (GTK+ 2.24.31; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, 19 May 2021 21:17:43 +0100 Aaron Tomlin wrote: > It does not make sense to retry compaction when a fatal signal is > pending. Well, it might make sense. Presumably it is beneficial to other tasks. > In the context of try_to_compact_pages(), indeed COMPACT_SKIPPED can be > returned; albeit, not every zone, on the zone list, would be considered > in the case a fatal signal is found to be pending. > Yet, in should_compact_retry(), given the last known compaction result, > each zone, on the zone list, can be considered/or checked > (see compaction_zonelist_suitable()). For example, if a zone was found > to succeed, then reclaim/compaction would be tried again > (notwithstanding the above). > > This patch ensures that compaction is not needlessly retried > irrespective of the last known compaction result e.g. if it was skipped, > in the unlikely case a fatal signal is found pending. > So, OOM is at least attempted. What observed problems motivated this change? What were the observed runtime effects of this change?