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 41837CA0ED3 for ; Mon, 2 Sep 2024 08:11:51 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 8F1128D00A0; Mon, 2 Sep 2024 04:11:50 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 89F8C8D0065; Mon, 2 Sep 2024 04:11:50 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 7197D8D00A0; Mon, 2 Sep 2024 04:11:50 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 4D2B88D0065 for ; Mon, 2 Sep 2024 04:11:50 -0400 (EDT) Received: from smtpin11.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id D4EC2121ACC for ; Mon, 2 Sep 2024 08:11:49 +0000 (UTC) X-FDA: 82519079538.11.55F753D Received: from mail-lj1-f173.google.com (mail-lj1-f173.google.com [209.85.208.173]) by imf28.hostedemail.com (Postfix) with ESMTP id DEC26C0002 for ; Mon, 2 Sep 2024 08:11:46 +0000 (UTC) Authentication-Results: imf28.hostedemail.com; dkim=pass header.d=suse.com header.s=google header.b=bxY8Kk2a; spf=pass (imf28.hostedemail.com: domain of mhocko@suse.com designates 209.85.208.173 as permitted sender) smtp.mailfrom=mhocko@suse.com; dmarc=pass (policy=quarantine) header.from=suse.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1725264633; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=NGvD+BjgTTmOW/uciXFa90rfCMl9ykoBAkblULS1a0A=; b=j2WsLk3u18Y6/yV3k3lVs4k+Jvux5bi1zPafFBiQ1bMi7gbAmirvPD2UFbvWT18nZ/sC0y K0igsdJ+4ZaTFeAZcPsLQzCZI+xM68mrq0n8n796i/Hk3HzrUlf8pbBEmzxYG97X3jtYJD 4hJNpQAGXQTfrwTPy4WBO+SKPC4rA9M= ARC-Authentication-Results: i=1; imf28.hostedemail.com; dkim=pass header.d=suse.com header.s=google header.b=bxY8Kk2a; spf=pass (imf28.hostedemail.com: domain of mhocko@suse.com designates 209.85.208.173 as permitted sender) smtp.mailfrom=mhocko@suse.com; dmarc=pass (policy=quarantine) header.from=suse.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1725264633; a=rsa-sha256; cv=none; b=J33k5oH+beu4zY8Zxs8QYyVbnSZx8ZuvTJYCZ/d3qCvMW7gSdlWkH/+f5R4tmRlohkD89R JsO54sFJ9sqHx1DLdMzBF1rLBS9X96FhdpSUk/xACa2BqZk16L+cidI7s67NtME9WHtX43 suzvqeHpze8DvnlGI/jRj4j9JaP5/1I= Received: by mail-lj1-f173.google.com with SMTP id 38308e7fff4ca-2f4f8742138so42826771fa.0 for ; Mon, 02 Sep 2024 01:11:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1725264705; x=1725869505; darn=kvack.org; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:from:to :cc:subject:date:message-id:reply-to; bh=NGvD+BjgTTmOW/uciXFa90rfCMl9ykoBAkblULS1a0A=; b=bxY8Kk2a4NI+BVgNjCBQvtgP/9G317hwJif460cuqmu4jq1FGWHkxvoolg6zCqjdiP GwwCfbkee88cufq0aZYOHW6FQ5epmCxZ+D9G5vx1ayeZIubZqs4y0FG10G72uG24LFEn 9RKng3yWOn3VGkYiXgcyGgsam3wyF5weWH/Ol8Dbc4+pJfQiL1WApEGl0a9LEKo4lMTW HKiQJpPJOsKJdOtTRJZptNGdgBxMKF26jvm98wCelQxg59PKtWSkYWTWSJTISX6ktH5b bLestWLbun0tdHHGV8e6MHH+vyHKzQq2G34PqOyJ8Te8SRcEA3t62u6S7Kxb+t9h9DK6 YeiA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1725264705; x=1725869505; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=NGvD+BjgTTmOW/uciXFa90rfCMl9ykoBAkblULS1a0A=; b=xDeVk/12o3/WEE37lWmxsfVvw2ZA8EWazzuKngFn0vwhycg8ErFcnTUMo4qfQR2jAI 72RKWDQzOKVwwPWW/RRiDQ7PIbHJYhSxxzqeLLQ8h9sA8m6+bpfMUfH50QDHtVBRGhV1 TfH7mepo81eJFJWb0L2/vz7XOgKk76mjcqzKhx2P8AtjkbTIDM4W3+aLZxYIlLP6xegu 3StUO0yLpoAbgHNO+0N24FOUbtL39SUcAmjEDYBGgwWluN1JFltPykGpRNXo4LxvL/Xn D/PFJaX1AmYQCnjn6PQguiJRxrkPjCxDiRLsotSRC6oMGO605GIGrjW9dwbhTpj92Gnq 4QLQ== X-Forwarded-Encrypted: i=1; AJvYcCV1jpMO9G9F6aO6/AZgavtqdutYkC0MoLl2k8llQIF7jq0NXZYlDxt/nfsd5EnmEPno2QscSv5OoQ==@kvack.org X-Gm-Message-State: AOJu0Yz6KR13fJWKUF1BgWnfRSidMWFm+B2ghVpeiVkTpgcSNiYovav4 csFRWCMr9jHexIrV3dCTFLyvUQzEfaabpK9riRbS5dLfVMt33HBygcH0JOWDQKg= X-Google-Smtp-Source: AGHT+IEYuCcPm4Oa5/lRr8JA2e8+k/oUcobDB31K+uGnsFShL4OmLoxo2s2kxDZjerkPq2Xa0E+SZQ== X-Received: by 2002:a2e:f12:0:b0:2f3:f8d7:d556 with SMTP id 38308e7fff4ca-2f6105cd99emr71774921fa.18.1725264704821; Mon, 02 Sep 2024 01:11:44 -0700 (PDT) Received: from localhost (109-81-82-19.rct.o2.cz. [109.81.82.19]) by smtp.gmail.com with ESMTPSA id 4fb4d7f45d1cf-5c250edd2e3sm1832543a12.27.2024.09.02.01.11.44 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 02 Sep 2024 01:11:44 -0700 (PDT) Date: Mon, 2 Sep 2024 10:11:43 +0200 From: Michal Hocko To: Yafang Shao Cc: Dave Chinner , Kent Overstreet , Matthew Wilcox , linux-fsdevel@vger.kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, Dave Chinner Subject: Re: [PATCH] bcachefs: Switch to memalloc_flags_do() for vmalloc allocations Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Stat-Signature: 4xe5zxdr6obwntixe68bzdmgijk753ea X-Rspam-User: X-Rspamd-Queue-Id: DEC26C0002 X-Rspamd-Server: rspam02 X-HE-Tag: 1725264706-523691 X-HE-Meta: U2FsdGVkX1+kOLbzQ8hqzfhk/7pI5ca6ovg41U5PLDh/YMvipe6MwiJc+IvVdXP5mbh4Mn5lky7R5cYa1mREwpl+JqWfp6EKlb9PgcVh0+31pZDJdZbXrZAaM4+lltfZO2SD8wlicYcI+o7ILtygY3dgzRB3xWFvdJUhUM67HJtloYrEXaRxEt/DcjHgIVnT8pfiODLIVnu9uEgFeP8+Tij7x03jEFsu4rK/iHDfFENvAkFtyrAHqkSErUmmRhyWMTy41/tT7FlOsozHwwJY6LIm/6p/+ZcSuStr8Z1D8CnLfGMzL9x44iN/Zh3EIdiK+fPgVutsmEbQyahQEtd7eXf6gLKT+QBw5/kw5TOAEFJ5HzZup7wBBrnoxrOd6oo1uhPliAXS3MK3anbOvHGDb1W3cmR6+ctrV2u2Y+wneBTz4F37YVKPQh5gcZWyc2lg3cHydOiUG/DGhD9qu+/N8R7K8ZSKCVLwS3qaOT/jpQxHAWqHWtXCs5veyU8jSnfu/5IE3+FPZO/REC9FMA6UGJq6n6pi214/RBjK8QY7+BVmW9K963jKYki6T+7mKuarKR3zJZEjlwBVa1Ar+1AUK450kp7EtbpVqAly9x8e/PdL+KQ5qD5XVFdF8lClk36SKkx0l8NOUi3knwbkoKVEhoT4cnJ5STGfNV3WdfJKFD+AVdIo1OtpyUhr99wQY8VkaJvGUXt9gGI3eAM58wO4pWhmOCEm+FovCg3uM6o0Fv4xslHlv+jpJUY/WQYdjCrIVmjXm/IfzUi+/ZrRjyEFWjvFnVgr5nlVyHw3juAHfgzCmQdquKnEEII0M19aMAHur7y0b0JlUyaI4LhgpVyTUTOCE+Dt1/HTDXWKkx9rwQ3lIR718bQlrLdM75sSmH+VKVaPEMYjpeyLrF7LkG1EJRh9PE6t7vHg8ce9N59aeuPFVsWATVqv0mg8/yHkB0DidMyPWsfHHGOVeBoBd86 a4lC++fx nucIRAhToLWlfqtzOCtARw+lasbhNAJv8/vaTRtekoK/o/ARZLkNfEZc2Och1p/KQAUEvcxo3XsPOszm+2d+Zjvx258VXGJ2QFdmWtjEvwttVPYW3a1SzG4RYYs53TMN1iFDIuX0Mr0fZfUQMLdZC/SCS9IlZ8Jno5xfDdnJfYN7KsAWXZzAQrYkMMUQJVUvPQkXtPmOGmx1XSXM60OHUGQYiJKXMdNA3IcpP1DJfRY/hdbgn++uhnsjrhT2oAjHRC2oXK7eHZ//zEzvCQ1hpjnTT1VXhq4DspVfd4Mr94Q4GvQyo+ZfJBmuXWjqsQDdwfKw5KPudhIrRrW1xogHjqnJKBTrfqk7GW6i00AEoXy7qRBLeOg1ylywF9RVmoFR0I3RfXKU1Am1O7BM+GVrjzVngAROG0KwQipK4J4KCKPrUhRuKn73emeznQZXcWvWhy8aKpLiA+FWXUb1RYRgB2UAzlXQVb9pEgFX79VR3/MpMxTZau/HpF/2D7MAM6QaIrsZx X-Bogosity: Ham, tests=bogofilter, spamicity=0.006709, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On Mon 02-09-24 11:02:50, Yafang Shao wrote: > On Sun, Sep 1, 2024 at 11:35 AM Dave Chinner wrote: [...] > > AIUI, the memory allocation looping has back-offs already built in > > to it when memory reserves are exhausted and/or reclaim is > > congested. > > > > e.g: > > > > get_page_from_freelist() > > (zone below watermark) > > node_reclaim() > > __node_reclaim() > > shrink_node() > > reclaim_throttle() > > It applies to all kinds of allocations. > > > > > And the call to recalim_throttle() will do the equivalent of > > memalloc_retry_wait() (a 2ms sleep). > > I'm wondering if we should take special action for __GFP_NOFAIL, as > currently, it only results in an endless loop with no intervention. If the memory allocator/reclaim is trashing on couple of remaining pages that are easy to drop and reallocated again then the same endless loop is de-facto the behavior for _all_ non-costly allocations. All of them will loop. This is not really great but so far we haven't really developed a reliable thrashing detection that would suit all potential workloads. There are some that simply benefit from work not being lost even if the cost is a severe performance penalty. A general conclusion has been that workloads which would rather see OOM killer triggering early should implement that policy in the userspace. We have PSI, refault counters and other tools that could be used to detect pathological patterns and trigger workload specific action. I really do not see why GFP_NOFAIL should be any special in this specific case. -- Michal Hocko SUSE Labs