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 X-Spam-Level: X-Spam-Status: No, score=-6.0 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 2CC46C433DB for ; Thu, 25 Mar 2021 21:02:07 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id A571261A26 for ; Thu, 25 Mar 2021 21:02:06 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org A571261A26 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=redhat.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 33CED6B006C; Thu, 25 Mar 2021 17:02:06 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 2EE936B006E; Thu, 25 Mar 2021 17:02:06 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 18EC76B0070; Thu, 25 Mar 2021 17:02:06 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0027.hostedemail.com [216.40.44.27]) by kanga.kvack.org (Postfix) with ESMTP id F0D806B006C for ; Thu, 25 Mar 2021 17:02:05 -0400 (EDT) Received: from smtpin34.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id AB36552B3 for ; Thu, 25 Mar 2021 21:02:05 +0000 (UTC) X-FDA: 77959619010.34.B6A5623 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by imf27.hostedemail.com (Postfix) with ESMTP id 4B21F80192E9 for ; Thu, 25 Mar 2021 21:02:02 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1616706124; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=W5uo0szkizrocSugHz9ejpS0qJiw6xbcngEnKme8A3w=; b=DRhp5GmgffsIEwdlJweR9xRAwq6jh+UoJOKaMeCa4XrhLmqtGFEpo6LcXbtpj+9gxYvrCF O21I1kLue9oqelhDJuHX5UiggkzehrJiWsKMnl8S9uLH03jpPrsNj5X7pJaVHDAwZI9Xht r0+T0VWv9tQxU/zm25twFMmCRn/Rgig= Received: from mail-wr1-f70.google.com (mail-wr1-f70.google.com [209.85.221.70]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-346-dPbNE0njPraAK9366-f58A-1; Thu, 25 Mar 2021 17:02:02 -0400 X-MC-Unique: dPbNE0njPraAK9366-f58A-1 Received: by mail-wr1-f70.google.com with SMTP id m13so1898970wri.16 for ; Thu, 25 Mar 2021 14:02:02 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=W5uo0szkizrocSugHz9ejpS0qJiw6xbcngEnKme8A3w=; b=ReJ8KeqsRJ6cRbO5k7C/k7Kieyp8Pd1NkRJzqo7ZRtqZ6RD2OEZXnCWDQUiSd+oq94 a9jgFwvavuHrMgNXlskWKn4kfHjZbgtCYPpwCo1DQ9Ry6EuCINR2WmBeDN+0aD1+/0tU trPYp4Qo/HUvzdPxXdhyeCse1bI7wh6jAh9FS658+2A73cTNjy8YkVulUvsPhUNVfdn/ GV8uSs64liZ9JtEHp7dNg7aVuhG5mAUsOTu9fTneTaQv3jVkvXHD3gHUZUOVpF8KZlma bgFXSGIvMLKr/KN/bXJoFAbNZymM7suF/lFW1Eb/RRq8biECSt22Xc4KwjkLCZRibCmT LitQ== X-Gm-Message-State: AOAM531/smMyezuS1zYok4vHsAMoTHdcKUZfrsR8ASGQCaZzJ/SeEBGn a/n4rElBrurXtpRtyM50ZywsdezytoCriBnqjqGOX89tIPQeFAyF9cfaXbo7aDvm4GEi33Zpsge dMthzET4skg== X-Received: by 2002:adf:c70b:: with SMTP id k11mr11186611wrg.165.1616706121124; Thu, 25 Mar 2021 14:02:01 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxLIOZWDTO2f53ZXf39F2RPQwNxKCIq59rzuOc4rl/gYCdm9FJ9Aat7Jd5M4vlwVDQQ16tI+w== X-Received: by 2002:adf:c70b:: with SMTP id k11mr11186585wrg.165.1616706120773; Thu, 25 Mar 2021 14:02:00 -0700 (PDT) Received: from localhost (cpc111743-lutn13-2-0-cust979.9-3.cable.virginm.net. [82.17.115.212]) by smtp.gmail.com with ESMTPSA id l8sm9195914wrx.83.2021.03.25.14.02.00 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 25 Mar 2021 14:02:00 -0700 (PDT) Date: Thu, 25 Mar 2021 21:01:59 +0000 From: Aaron Tomlin To: Michal Hocko Cc: linux-mm@kvack.org, akpm@linux-foundation.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] mm/page_alloc: try oom if reclaim is unable to make forward progress Message-ID: <20210325210159.r565fvfitoqeuykp@ava.usersys.com> References: <20210315165837.789593-1-atomlin@redhat.com> <20210319172901.cror2u53b7caws3a@ava.usersys.com> MIME-Version: 1.0 In-Reply-To: Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=atomlin@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Disposition: inline X-Stat-Signature: putm3ftccy5874ttciib5etyprgb1ocb X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: 4B21F80192E9 Received-SPF: none (redhat.com>: No applicable sender policy available) receiver=imf27; identity=mailfrom; envelope-from=""; helo=us-smtp-delivery-124.mimecast.com; client-ip=170.10.133.124 X-HE-DKIM-Result: pass/pass X-HE-Tag: 1616706122-218503 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 Mon 2021-03-22 11:47 +0100, Michal Hocko wrote: > Costly orders already do have heuristics for the retry in place. Could > you be more specific what kind of problem you see with those? If I understand correctly, when the gfp_mask consists of GFP_KERNEL | __GFP_RETRY_MAYFAIL in particular, an allocation request will fail, if and only if reclaim is unable to make progress. The costly order allocation retry logic is handled primarily in should_reclaim_retry(). Looking at should_reclaim_retry() we see that the no progress counter value is always incremented in the costly order case even when "some" progress has been made which is represented by the value stored in did_some_progress. if (costly_order && !(gfp_mask & __GFP_RETRY_MAYFAIL)) goto nopage; if (should_reclaim_retry(gfp_mask, order, ac, alloc_flags, did_some_progress > 0, &no_progress_loops)) goto retry; I think after we have tried MAX_RECLAIM_RETRIES in a row without success and the last known compaction attempt was "skipped", perhaps it would be better to try and use the OOM killer or fail the allocation attempt? I encountered a situation when the value of no_progress_loops was found to be 31,611,688 i.e. significantly over MAX_RECLAIM_RETRIES; the allocation order was 5. The gfp_mask contained the following: #define ___GFP_HIGHMEM 0x02 #define ___GFP_IO 0x40 #define ___GFP_FS 0x80 #define ___GFP_NOWARN 0x200 #define ___GFP_RETRY_MAYFAIL 0x400 #define ___GFP_COMP 0x4000 #define ___GFP_HARDWALL 0x20000 #define ___GFP_DIRECT_RECLAIM 0x200000 #define ___GFP_KSWAPD_RECLAIM 0x400000 -- Aaron Tomlin