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 96023C3DA7F for ; Thu, 15 Aug 2024 06:51:58 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 1EECB6B0083; Thu, 15 Aug 2024 02:51:58 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 19F286B0085; Thu, 15 Aug 2024 02:51:58 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 03F6F6B0088; Thu, 15 Aug 2024 02:51:57 -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 DA6206B0083 for ; Thu, 15 Aug 2024 02:51:57 -0400 (EDT) Received: from smtpin19.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 5965312129A for ; Thu, 15 Aug 2024 06:51:57 +0000 (UTC) X-FDA: 82453559874.19.C6A13E9 Received: from mail-lf1-f49.google.com (mail-lf1-f49.google.com [209.85.167.49]) by imf27.hostedemail.com (Postfix) with ESMTP id 4BDD840007 for ; Thu, 15 Aug 2024 06:51:55 +0000 (UTC) Authentication-Results: imf27.hostedemail.com; dkim=pass header.d=suse.com header.s=google header.b=A7914fG1; spf=pass (imf27.hostedemail.com: domain of mhocko@suse.com designates 209.85.167.49 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=1723704642; 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=JmIL7LdkrSJnWarm/Yb09EWfXk7ckLUYXr1SgfRr1lI=; b=rinrxKJfT1kGDMyu+fXfhL27GBlHjnJp3kt7H9Lre8HUUK84hOo/2VqMykIlVDTCJx/whT K5LgQgAv0GucJP5Hb9aqz0tM1YBmiBd0JGxgv1sNnjbqqakIWhWIeK2vXdRSzw1kSmZZ8v NkhtGOTdb7Hd9tBN5cY9QN6o3k60FJo= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1723704642; a=rsa-sha256; cv=none; b=GcHdf+7NI+IYW3h/olQiiUyIwGv/bnyLwNqQezLGd/Exxgjcx70eD3gSTBfS8arXDEX1Cq ikqd7zUR5TpelGvYrgK6KN6heLkVph5RWkArcKqVXr07VBM8wEJDPj7Ksqi5A8IOmlyCGS GloJ01YVdvN+KdrG1dfO2aboj0NlHmc= ARC-Authentication-Results: i=1; imf27.hostedemail.com; dkim=pass header.d=suse.com header.s=google header.b=A7914fG1; spf=pass (imf27.hostedemail.com: domain of mhocko@suse.com designates 209.85.167.49 as permitted sender) smtp.mailfrom=mhocko@suse.com; dmarc=pass (policy=quarantine) header.from=suse.com Received: by mail-lf1-f49.google.com with SMTP id 2adb3069b0e04-52fc4388a64so813992e87.1 for ; Wed, 14 Aug 2024 23:51:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1723704713; x=1724309513; 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=JmIL7LdkrSJnWarm/Yb09EWfXk7ckLUYXr1SgfRr1lI=; b=A7914fG1tYMzdvxc0OJTvvyCTJwPRUfvN3y2EgZU04rYwZfhdxptJTGHRaFRvd42UQ uRcH2BteLS82LdfF0fPNTy/n6kw7ZjUXpbdq6wALxKrliq5Nh1e5wZRs30HnOkrhGyFO /+xzVO3S0gsEDGAw6CjTIsuBl4HR2auCEAhFHuM4F2tHopl0UXNYPFk++PWzA5BxtoEm oeUlX3WeJj7hFGDJjEYkEH+igO7k7gdnr1TSiO0+OM/a1eEnEtbA3elr5dZOGPU5k3TR o6gOsFnCC+57bQzUHKBLDHZz5mMcx7jRUEuKicjTsTFCe94uZITMB+aJjboXN/Q3MpI+ Rblg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1723704713; x=1724309513; 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=JmIL7LdkrSJnWarm/Yb09EWfXk7ckLUYXr1SgfRr1lI=; b=KUE15ystjBmbesTK+R056vzPXRhhl8fviY7iS7st+kafqZOsV2FPlD+YwSWJwFHJGu idAR5+wiFcDOjJDrGSTi0TZ+VrlNpxU56148vuzJ9sCzz2eL1ncBEJFQVNMZYJ+Zo0Cq MtyfWwWIfnlBYyL9EZeIwUESg4UwxGrCysx76Okj8jrk/OVjYfdvKkp+D6k9UysOAgf1 hmSvKHnCLg/icep4IhmqcWNnGLfInhL82KyKhUy+fTp6oS5C2kXREwpgf03Wh1mrUa/V UUHPMRG/N0Yfx0MtkTZFdxZjJfS9o6P0n9KibbHnPu9dLQjFCjFVbTRBiOUkPF1Udmo5 8fBQ== X-Forwarded-Encrypted: i=1; AJvYcCUxdlkCPN9VZ5cf1GKtsxFuvXx7qRAcApVA6hrFsM2yOKeVLc3dJ+fpfbr72pW+rx9sflLlywR0APYjgTVkRrxDbMM= X-Gm-Message-State: AOJu0YzTq0K2ETAGUxtR2RA62uAfpo0UgAekq6rnVB1jMpIdB4PTylWv D65e1w3vJ5pLJqB2ERxLl5cPA4iw+x0QQVSH/Ahoi6YKpr8kBg+xDs5w7bvzdeM= X-Google-Smtp-Source: AGHT+IFwhq19K7ukguDKaa6fCaMlS2KrVMj1ZwOSqmmgXzCAC6R6TyEqxonkvPUbLbchw0OeA40EVw== X-Received: by 2002:a05:6512:318a:b0:52e:9905:eb98 with SMTP id 2adb3069b0e04-532eda95c8amr3189049e87.35.1723704713255; Wed, 14 Aug 2024 23:51:53 -0700 (PDT) Received: from localhost (109-81-83-166.rct.o2.cz. [109.81.83.166]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-429e7e1c46fsm10404615e9.39.2024.08.14.23.51.52 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 14 Aug 2024 23:51:52 -0700 (PDT) Date: Thu, 15 Aug 2024 08:51:52 +0200 From: Michal Hocko To: Yafang Shao Cc: Christoph Hellwig , akpm@linux-foundation.org, viro@zeniv.linux.org.uk, brauner@kernel.org, jack@suse.cz, david@fromorbit.com, linux-fsdevel@vger.kernel.org, linux-mm@kvack.org, Kent Overstreet Subject: Re: [PATCH 1/2] mm: Add memalloc_nowait_{save,restore} Message-ID: References: <20240812090525.80299-1-laoar.shao@gmail.com> <20240812090525.80299-2-laoar.shao@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Rspam-User: X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: 4BDD840007 X-Stat-Signature: 7yey4zhuie5czrbbgbd46aaq1ojdm7uw X-HE-Tag: 1723704715-866542 X-HE-Meta: U2FsdGVkX18t4OCeDNf+l3IewzAgIQfem++UwYuZ9jWv0wRfJRKh5IIFtrQZBKvB7lqRueBYQszicFRxAfizo4OVAhKbQ7W1vscTNTAD9u/NJxBzmOhU3jTwr5G1A3hQEGOXHF0K6m3/FeUg/qtH771v/Ic5iZp5xCu5D3ffxMhZZMScbby+Ic8gV87dWuBkH9OSC5lTTIO/RqdCDo3GiC2tELjbYVxtNLwjADa24kN+L15UbZhI+RA+oPZsM1Aj0BvshhX1tVD5UXvQYlzhbD1DlCvHbptIxgTtIJxLIk7cpFp49l+XWUoAnbaCHOXN20iSHzw8yOHuaSZ3hE2pSoyDN0Dfg1vqGOZHpoCoMYwdvzbxdrApUi8z6l/kibmjCxW0KKFjcS9J0/+nf36nHQaT2hIIhGQMby8X7XGXUo0icz2LuIEhX4fTPTMkqtm5y5ILg1wrL+OZ798g1itfGb92yBUSj92jyiiURgEp3p9CKaJERewA6OEJFdEJ74+WaYcNNUUfpRyKFfRoFrh6Vr8v5bvtmvw/rf1IPCzYZidlhk1R8ptT7dKPjPYSItkps123lAUpjacaaStsKEVcagjF0TPb4Fhw3IdFzFzhOrq8b06ACK/YnNqBLLcYdpokTzsfnxcQeXgBVN1zbtRXGjUtYCwN5bkiZGpYP4XjuJO4u/Hdgzw8HsZNEfzT49KICZ4rVn/PB6ygi42HM5ixwMkcipLvFSoWiWUPc/w6nGQHfaYpPrWJt6LbBC+U4ak0DRUAU1H1kCHDQX2iaCONvsrMgxAV9CVweXlDhiFyzCJhWo8GN2BZIApZuSMx6msoGtEgYeRTSysebllLZi6gXGnd8W7YkZtTgABuPM1ryMNChkYR3z3v5Sxx3uVb3SQ0rtoaLMx2IAZ1KXtHhizr4DBLENr1tybtlco4VvE2/bJpLJPVT9ZPkhkjhfTFOGeAXLSJqiX+JFTMZYSIwB5 9QdG6Boq 94O0FWHmAH1IJoSiqa5yOksmEOmB0Gwc2nbkK2ZHUjz6fb3SSGfUDSOLGVS5CWeXNV23nCy1RcjmJOkd3mTtgeGqx1argXgw0uVm03EP13icDE8AcsCy8iztkBohYUO0jWNMJa3Aw0jhfRHopJh6/82I/j4UjRIiY4GE/a+9y1FH91+isDZMnzIzdhEYbMFROAYumwSm7JiBlkQI3eZFzdyStIDkmjbredUuCdqlWoywYYV0EpXyRPgyNaPZy9XItGDFzShvAoOrXK0i9xVGbRrpHeHLTMzHxBmllg8Fs0TURsVvx0lW4aSawWHlth8xDvExjJMaqHHqV9Ft1KpNtsn5KloTLWRvMIO2peZMmELUY75mNKAY2UZXo4vIVzZh6QBmVAArOY690bbaXZsPfjx6QeqQ7qfo19a74lgEWXFfurLc++X9qUOtRAURujqcsDtOAqI4SbNmqcKEknU4l1r1p0erUWo69DFpe6eyRoFjlxVQ= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000425, 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 Thu 15-08-24 14:32:10, Yafang Shao wrote: > On Thu, Aug 15, 2024 at 2:22 PM Michal Hocko wrote: [...] > > Let me repeat, nested NOFAIL allocations will BUG_ON on failure. > > The key question is whether it actually fails after we've already > woken up kswapd. Have we encountered real issues, or is this just > based on code review? Depleting memory to the level that even min memory reserves is insufficient is not a theoretical concern. OOMing the system is a real thing! > Instead of allowing it to fail, why not allocate > from the reserve memory to prevent this from happening? Because those memory reserves are shared and potentially required by other more important users which cannot make forward progress without them. And even with that, those can get depleted so the failure point is just a matter of a specific memory consumption pattern. The failure could be more rare but that also means much harder to predict and test for. Really there are no ways around non sleeping GFP_NOFAIL, either you disalow them or you just create a busy loop inside the allocator. We have chosen the first option because that is a saner model to support. -- Michal Hocko SUSE Labs