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 D754DCD342C for ; Tue, 3 Sep 2024 07:18:37 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 6C91D8D0143; Tue, 3 Sep 2024 03:18:37 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 654AD8D013C; Tue, 3 Sep 2024 03:18:37 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 4CBDA8D0143; Tue, 3 Sep 2024 03:18:37 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 2B59F8D013C for ; Tue, 3 Sep 2024 03:18:37 -0400 (EDT) Received: from smtpin23.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 8EE28C095B for ; Tue, 3 Sep 2024 07:18:36 +0000 (UTC) X-FDA: 82522574232.23.78F2AE9 Received: from mail-ed1-f50.google.com (mail-ed1-f50.google.com [209.85.208.50]) by imf14.hostedemail.com (Postfix) with ESMTP id 997B510000D for ; Tue, 3 Sep 2024 07:18:34 +0000 (UTC) Authentication-Results: imf14.hostedemail.com; dkim=pass header.d=suse.com header.s=google header.b=gU9zFKae; dmarc=pass (policy=quarantine) header.from=suse.com; spf=pass (imf14.hostedemail.com: domain of mhocko@suse.com designates 209.85.208.50 as permitted sender) smtp.mailfrom=mhocko@suse.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1725347838; a=rsa-sha256; cv=none; b=5e1llSfnSGWXSVAAYEGPFv5LryurlvHijEs5RJl6h/ASev5azRQl3GY7Zyf+mTpCfP7KED iAcG2F+qO6BcBAE8IgBA/vRELOF5kGVRCblNoDvQyT/35LvEZ6Co27m5/TZEH/M6BKfkb9 yYzpAF8K/TZtcaNbZ34zt0EUi4yGiV4= ARC-Authentication-Results: i=1; imf14.hostedemail.com; dkim=pass header.d=suse.com header.s=google header.b=gU9zFKae; dmarc=pass (policy=quarantine) header.from=suse.com; spf=pass (imf14.hostedemail.com: domain of mhocko@suse.com designates 209.85.208.50 as permitted sender) smtp.mailfrom=mhocko@suse.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1725347838; 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=O1FUH7RDqc8uXX+mkPWVfnuu8rhsu2/+E91M6Uiz5sw=; b=K31J+kMh/kzBtRH+Lusd0E9T20PIg4ZyF58b495/gsdUa/0GBrz7S/DkTgNiCSTPOYaoiO V4LQ9W/7ZisDYum+iDyZ1Yl806JQW9BNVNizqG9A6WZZ079boojXoze9mv9HW6NizRp3s+ 2tHbDTQOLNqkgfPpf+Lxzgi6YFCGQVg= Received: by mail-ed1-f50.google.com with SMTP id 4fb4d7f45d1cf-5c25dd38824so1135092a12.0 for ; Tue, 03 Sep 2024 00:18:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1725347913; x=1725952713; 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=O1FUH7RDqc8uXX+mkPWVfnuu8rhsu2/+E91M6Uiz5sw=; b=gU9zFKaerhrNmA/tldSuYt4h86F612ihH81AcK/2ph6/QUBuON8jIbvkYDfquWPRUY v5/GMYMgESdqvQqo6L1HOt8F3raq/cm5j3pkEV3XOSOswA8OWUlV0OW+Vjlo7C+ggJsa +l7KuYiISB19HAvAoX7tyVi8KGdxMwTzw3uffZhpMIXVaJc/lLjbOpMz70sWRWRk8WY1 ctDmdXGAYGrYYJKJ8My3X333jPR+0Fn3R8nft8YG0sdzC2epds+Ffng040xxnr6lfOEj td7MOroBN5f7KAjJ0qMG+lcygSnEGWuIA1Q/Fh7bNgIWTbBiIQXnJ5O4uyCMGtigZvmN 4SSg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1725347913; x=1725952713; 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=O1FUH7RDqc8uXX+mkPWVfnuu8rhsu2/+E91M6Uiz5sw=; b=fB/VjJmIGe6yEYPR+gmg3A/4p79p7qYnMmecTuvt4xU3qRbNSEMwuI9/WA3TdM55Ln 4gqXHYggkzQXqx8hxQ8eZ6Gl7QMzZqCToLnqX+INRaYzgTa4B9iKbGns+CFQTrI/NQB5 JzdgeEBGWP0tx5o/T18oYW1EvDMgdPR9vuSOyof30jkOI/u3vwOHpNGGZ2fb0toqV1le flNBsXh7qQHZeV0AblP4GvOdwrnzlvfRfSR4eqSzkk81WzX0ZYyu0tgcWRUlUF6cajXv /2Uc2KmvG0Gn0Vnr2j9ZuKUT+F7sxmAwVvZQ+LIjh0M74IzDcXGzWZrMS2DOxuep36oD eaYw== X-Forwarded-Encrypted: i=1; AJvYcCVy3PWkPe4zrziigSUncSbAZflIAdxmscjlVbf9s2VL85/9riFzSgaL+edHdctfqwHDv1yhUMjPow==@kvack.org X-Gm-Message-State: AOJu0YylIuNVxt5oaJx3sGQ580OavqEiFDV7SsC9e6dSab9u8CmZPdJQ +FDjui4qEQwDUR8iluGiKqlak/M4dYKSC6e52tYdz26l1aywQVXM93nNlexJOcU= X-Google-Smtp-Source: AGHT+IH7o8OBuxsYo0So55zp2XL6wxWiUBp8CJS3P4zLH8eKh+LWdli7JkGefznOKzzc3ienqUEupQ== X-Received: by 2002:a05:6402:5186:b0:5c2:1014:295a with SMTP id 4fb4d7f45d1cf-5c2200de37dmr16495409a12.2.1725347912777; Tue, 03 Sep 2024 00:18:32 -0700 (PDT) Received: from localhost ([193.86.92.181]) by smtp.gmail.com with ESMTPSA id 4fb4d7f45d1cf-5c255d3da3fsm2703971a12.79.2024.09.03.00.18.32 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 03 Sep 2024 00:18:32 -0700 (PDT) Date: Tue, 3 Sep 2024 09:18:31 +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-Rspamd-Server: rspam12 X-Rspamd-Queue-Id: 997B510000D X-Stat-Signature: 497i6dqwcgerpcwk9xocg5e8g951t5d7 X-Rspam-User: X-HE-Tag: 1725347914-333245 X-HE-Meta: U2FsdGVkX1+eXS5N2VwAFuIcz0H/Cuzi7xeFce6vX06pRBpKQUQ37ldwrrAZSude0jvYLce3E4QbjrEDaTM4oKx8Oiu5sDKhlzTI7dF3Ve2IU2n43EjeMIyydBccOYgKSsWgarWL9zDJEIK0CTPVOgPBMZ95DTlz7pG8MgqRMaWlJB1YcKCPtdVbOpmg2kzdUbiTT76Afx/mqZMu8wxthA2dQxGytW288nQV6o7f/33SLZJ2HzMAZIhe0Kwc42U6NU96aW52WYnkVRcFORiPviVrzAmTWta2GOsYos2VSipDiHZOLbi/gx44KIdU/++/e4QUUhMcW0cgu7qqYcR69NSBbZgoTqiCOUFjv8IVls4pyHdrrd70UjHA2djYSIQAtugFGizAdH5XQ8g2lANC1GYipkVuOWKPQ5WeGZP3jXWdOK/gwmoJgpmRXaOrz5Fz7iC06gcyS4TYIOeQSBRxqqrS19ScTurXwTHHhmm0hG+r/9gpxW8578C64/evodb4XC4zE6x6fv3V/lhbS/sJI0lnrsTQlOVIazJQOiGKMvXsXRo6i7glLO+HQZUDqGZkZhwf8EiRVhjzGK/9pMnDunrvYsGjGpjfFod8cGwlAm3B03EH3J7Vj/L+vWMD+3+k5UfNh56HZh4frJMHQ71uh9w4/zRQj/7sn48cIUAPfKtMvBuz0ZGEFhZg2Eim6/nqX3uidOZQiUpJZtDAWRLLCH5jNuh+GuzM4JyZxI+4HhofLw69RaMSyNrfDcFktKvtuYYIT+Y4o21hvmK5XMxUtc+o/hv+7BrHeF9/7Yx9ydh5vNkYflLy4cnLAdaqf9FmOSxDv15y3tPIag3RwcPcdkUJ0I3GojZeiSxOmoYzu7dZpYQO7QkNmdO9Am+eX8r6VbHaNSb6JIs+zCCa2q1e9brme921sivbjI0086kTQN6fUfmalcWnTuBlDp/nu1euMsPeRWlGb+AmSLoZqnA aRUWGjgP iuRW1wQu2dQARxOrYjn4a63Zt6UuNK4gNg8a7RU6wzNryp7UCZgH0QtBtRC6BqpMnLKnfMjMwkgHVUCmuzLgXPNb772T7eolXH7ow97au7Dk/KprYhWoWSN0Q7uG06VEL449A+X5RJjvWWEM0bvpSmU8ikvCg0lHQPw6TCEkxuWe9GmStDJIUUZGF/98/8IjPv+TGydeCZiGSDnRTAp+DBYni43GM4mN4/BD0ncgw7TiO9bygkVEJ7eQ2prMe4l2cuCRh0ZWAfPpJe00Wi4r9K4gp9jQZOsr2HNOR4kXsJ4NQciZU4nUOIGCWjp6scWUbX+kMBmy41hlkTj6aLw97Nw+U9a4ezUqVg0Nxkn8uP1JgF4g0L6oLp+m4gDMtplR1+I5GpP3C+QEqxc5883cgZ1cEPFO6H3D9Wec1XtaAQTM/aL3NgXEtUqrjrNk2pPhmeFnlyialS/7/z3IoU0jvRju9Z+spyyrxQMSeZ5j+Oanq/xFkUSZJqCXWXg9tvNqmcDEa X-Bogosity: Ham, tests=bogofilter, spamicity=0.028168, 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 Tue 03-09-24 14:34:05, Yafang Shao wrote: > On Mon, Sep 2, 2024 at 5:09 PM Michal Hocko wrote: > > > > On Mon 02-09-24 17:01:12, Yafang Shao wrote: > > > > I really do not see why GFP_NOFAIL should be any special in this > > > > specific case. > > > > > > I believe there's no way to stop it from looping, even if you > > > implement a sophisticated user space OOM killer. ;) > > > > User space OOM killer should be helping to replenish a free memory and > > we have some heuristics to help NOFAIL users out with some portion of > > memory reserves already IIRC. So we do already give them some special > > treatment in the page allocator path. Not so much in the reclaim path. > > When setting GFP_NOFAIL, it's important to not only enable direct > reclaim but also the OOM killer. In scenarios where swap is off and > there is minimal page cache, setting GFP_NOFAIL without __GFP_FS can > result in an infinite loop. In other words, GFP_NOFAIL should not be > used with GFP_NOFS. Unfortunately, many call sites do combine them. This is the case with GFP_NOFS on its own already. NOFAIL is no different and both will be looping for ever. We heavily rely on kswapd or other GFP_KERNEL's direct reclaim to allow for forward progress. Unfortunatelly we haven't really found a better way to deal with NOFS only/predominant workloads. -- Michal Hocko SUSE Labs