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 1B888C3DA4A for ; Thu, 22 Aug 2024 09:16:45 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 9A17C6B0290; Thu, 22 Aug 2024 05:16:44 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 91F426B0291; Thu, 22 Aug 2024 05:16:44 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 798B96B0294; Thu, 22 Aug 2024 05:16:44 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 558DA6B0290 for ; Thu, 22 Aug 2024 05:16:44 -0400 (EDT) Received: from smtpin30.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 0511EC13F1 for ; Thu, 22 Aug 2024 09:16:43 +0000 (UTC) X-FDA: 82479326328.30.1849ED3 Received: from mail-lj1-f180.google.com (mail-lj1-f180.google.com [209.85.208.180]) by imf07.hostedemail.com (Postfix) with ESMTP id 07CFB40002 for ; Thu, 22 Aug 2024 09:16:41 +0000 (UTC) Authentication-Results: imf07.hostedemail.com; dkim=pass header.d=suse.com header.s=google header.b=V3513Oow; dmarc=pass (policy=quarantine) header.from=suse.com; spf=pass (imf07.hostedemail.com: domain of mhocko@suse.com designates 209.85.208.180 as permitted sender) smtp.mailfrom=mhocko@suse.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1724318136; a=rsa-sha256; cv=none; b=SRyPdIOLSppySNPtJQNT50EZEXPURH3lQz4BRBuKY/WPdD27Nhe2apvPFZoibe0eTzo/RT uFSC9nzvlCEhpw3RGBUFs9OkgncaK6HmQt4e3UMsY4pXZVnI7utqqoZCANl4Pd4OgswnSj tsu3m91JYtiAUOybbj8BcavORwLFoQs= ARC-Authentication-Results: i=1; imf07.hostedemail.com; dkim=pass header.d=suse.com header.s=google header.b=V3513Oow; dmarc=pass (policy=quarantine) header.from=suse.com; spf=pass (imf07.hostedemail.com: domain of mhocko@suse.com designates 209.85.208.180 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=1724318136; 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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=U0Lq6Y4I+CSXI3kv77xC+HPYsP4G3D1iWJBZIcmDlUc=; b=go7OVjp1pvNZCfsxoLM2xMYtdZHFw67kx8gF0O3KavUhXY049uBSsI5VKHvYRydnyBa7BA G6X/hkeArSdSijmiDl+y5WtFRAQHmQJXV73gYkAfvYLGDRA1lTFAd/01mBNUU3bO4aTeWb qJyjbPlBrXQeZblzXHF15Z0pyh/hsNc= Received: by mail-lj1-f180.google.com with SMTP id 38308e7fff4ca-2f3cb747fafso6093131fa.3 for ; Thu, 22 Aug 2024 02:16:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1724318200; x=1724923000; darn=kvack.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=U0Lq6Y4I+CSXI3kv77xC+HPYsP4G3D1iWJBZIcmDlUc=; b=V3513OowS5pvD7I/raNMQzGsUEukGzdOmYrN/WtLHTOfjawd+iTWuOsMseeXr1m16+ /qLhhY0G4+NbGDu04jkuLD2iBEmwBCXC+j9j7BN4wuaQxxSgMnU5j4Jz9EYE6vPmjE5W LETN0eV8tv+vyX7CYFAWpbG1PlWthTlB3DfnVmFg7r6s4VNbSEeqGz29yyevcnpChZGy /N8eEs35ylEYaF5EHo4PZF75jDSxZ5D7eOE2G6AtAFMMdCLl3lNzFSEUm22RtfiqoFGE cuvoOslljTVJoYrXTXJ/OQBoyrX+MPcvRe9PGxuJdA86RB7KX0GnTxJBKXIqGWuJxaOw IfyQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1724318200; x=1724923000; h=in-reply-to: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=U0Lq6Y4I+CSXI3kv77xC+HPYsP4G3D1iWJBZIcmDlUc=; b=BgV7xdU2RFz/kPgJxVy0eW5fMs5de1m09UJPxnhFO64emG6Z7iSecnIM8R8PP5Vbb2 4aBJG8Ba0huOcgXoh9x/P1jvvSv2ASfRVQGO+aUa5uc1sLSxCFBHuhAXzp5ao0/Vl3qY qi7XCTOuGg/KD+cfQWLmOrFm+zRTxWbKvxlrPUoFWqljiWTjXchKMZdJzXFTHtfFBJWk e4XZ+W37EJ1Nf1yUD4I3ZrhecD7qpxc4VnKA8Ncmwx1KdLAPjgiYkMj0iomt1TpWIZPl 8WjXNLA8KVUIM+6TEYqqRD0j2nW3TR5TqdHX4H/Dl/tOs9dGENZnom0vJGZ8y8J0MW0B uspw== X-Forwarded-Encrypted: i=1; AJvYcCXhu5AUtsxayXfX0iEuhzPfy6vRaTzuuQ61gsurvbpo5C5lp0LNyqhZqBECBTW2M8lLr7XIeytYQw==@kvack.org X-Gm-Message-State: AOJu0YxUAXaMMwQ2Ek+C84fPYlAqyYKr3lTZdz4D3AOzdsXEx5F5u3yy foSGuEJG0Lq/Y92aq2vukFi+qZ7AyR5rdq/PxA2yfYz7QFaRv2cumnoV2Y1rFIM= X-Google-Smtp-Source: AGHT+IHey5fz87xcf2+59YzIPtjPhSZkzqW33/JXCuGkDvdIypnimWzYcIFv58faa0n9Xne1GrXYQw== X-Received: by 2002:a2e:711:0:b0:2ef:1db2:c02c with SMTP id 38308e7fff4ca-2f3f8862642mr29088661fa.10.1724318200030; Thu, 22 Aug 2024 02:16:40 -0700 (PDT) Received: from localhost (109-81-92-13.rct.o2.cz. [109.81.92.13]) by smtp.gmail.com with ESMTPSA id 4fb4d7f45d1cf-5c04a4c4377sm694072a12.74.2024.08.22.02.16.39 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 22 Aug 2024 02:16:39 -0700 (PDT) Date: Thu, 22 Aug 2024 11:16:39 +0200 From: Michal Hocko To: Linus Torvalds Cc: David Hildenbrand , Barry Song <21cnbao@gmail.com>, Yafang Shao , akpm@linux-foundation.org, linux-mm@kvack.org, 42.hyeyoo@gmail.com, cl@linux.com, hailong.liu@oppo.com, hch@infradead.org, iamjoonsoo.kim@lge.com, penberg@kernel.org, rientjes@google.com, roman.gushchin@linux.dev, urezki@gmail.com, v-songbaohua@oppo.com, vbabka@suse.cz, virtualization@lists.linux.dev Subject: Re: [PATCH v3 0/4] mm: clarify nofail memory allocation Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Server: rspam12 X-Rspamd-Queue-Id: 07CFB40002 X-Stat-Signature: npakasqfgzr5ymajxegkekuab4p9r7pg X-Rspam-User: X-HE-Tag: 1724318201-678199 X-HE-Meta: U2FsdGVkX18pxR9xA88/eG9ZEl8S3elvmOmia6mIcCPRclRdnwTvRFOwAcwviTfTzGERBETN7MqVZ872o/pRhbv9D5g/Q+03LdwWI6ncySlLEOMHKP0fIR1Kqo0mKz/foHO9w7fiI3EQlIueySIaklRy0MBgC5f9haViwSRGis6/31cRwzXYJlDrHlgMM3EFdnYquCMfSxxVqbLjCo3uCszX9d2iHVZc1P9TiHs6csHWbjpn1n0yt4etr7up3Ionn5SXVUpJ2hgrSsxdTsUxz+Zk2bO4Gthq8v3EGgF9rhQ5UTEgyfjDME3D3fUivbU18FKUGlgNofegnAaII3vozc+KJkM0eGXZFEQefvGgqHvJzGG3eUERoomnpr7SZel6LRqbyx7IQ5YsQYwo5Xab9NBTAc62oHTzZqXUx4Qw6eKjUsJ1SOP10bEhW7VtLJgC2CIA+Z57EJl1GrxP/aPikCU5DZRjo1ir643CYkKzyAHJnCOiPH60xMqDy7LIiMoaXWMhbWundY/aXL35QWyaEWqFgTQdef3vg31Syl8mD84nPpWxXI07CxTSs68F9LmTlcSXlPtn1w1BKg11UcNrsLJwYci2yuwubtIhKqaYlz7vwWs8ei/xLmr2Cm7X9+uOmiofP0vSI7k8uwvYye6O1EqgTdQ2Cm1R2UMijsigPRZrKoeGC45GFX/JilLSjLNhOdEvJzNAiJuGDC9Elo7EMUixe6m/rCT1bioh0CooY9DBVj29NuiQWiY92OwiFBVZhEgy+EQrkzYzF1VaJUx9Ev5h5GbvZdsMwhLktL+TeREhemQvEWcHSV44+7qR+pQAxPBBbFnzMCAWWTsE/lVig2aX+OLKXcvuAa6XftkrgGX00T9GN0o+YWQFYrejr8jSjbzcb3RAshu63Abx1pc0x21bEM2srtnM99Lxq1sUPnwYWZD6yewqJ8a9ckb2Dxjtr1SSSiScDBxYLLqys90 5+E+fGFE S74vqBA5FnUE2eEO7Kph6l1uWFEgEP+JAgRl6tZoJTEw4hhNNMaZLDxN1AG/mNveLe8rC6IlLpxvaP62t6/Ywiz6ru3CMj+hgdskQisqrhCBOKSAY4a93MIXFh7/lAoejzZouT1WLhJ+MafPiVhlbkEtfRo60UfkYZEXRmcZL4avDP+2ZNvehogWzxDhfNT+RWHUE3HnNam9CaezAkjwl/PP+n+iJZSGqtr0RwD6VDMIGNXlBfPd0+p64Sf3zZK6iNC/ZDB27hnBUniLQD0yTv/8pfiEvvzXamAHmJvvxNr6bmj570bitAZaJA34ed+L2R6w2rnZNXRhGHc0mp5n7NJ+bM81vGLIuAWINPLA5IW/eRwng4F3aDPa4ZatVlwwgxV4G 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: List-Subscribe: List-Unsubscribe: On Thu 22-08-24 17:08:15, Linus Torvalds wrote: > On Thu, 22 Aug 2024 at 16:39, David Hildenbrand wrote: > > > > Linus has a point that "retry forever" can also be nasty. I think the > > important part here is, though, that we report sufficient information > > (stacktrace), such that the problem can be debugged reasonably well, and > > not just having a locked-up system. > > Unless I missed some case, I *think* most NOFAIL cases are actually > fairly small. > > In fact, I suspect many of them are so small that we already > effectively give that guarantee: > > > But then again, sizeof(struct resource) is probably so small that it > > likely would never fail. > > Iirc, we had the policy of never failing unrestricted kernel > allocations that are smaller than a page (where "unrestricted" means > that it's a regular GFP_KERNEL, not some NOFS or similar allocation). > > In fact, I think we practically speaking still do. We really *really* > tend to try very hard to retry small allocations. yes we try very hard but allocation failure is still possible in some corner cases so callers _must_ check for return value and deal with it. > That was one of the things that GFP_USER does - it's identical to > GFP_KERNEL, but it basically tells the MM that it should not try so > hard because an allocation failure was fine. GFP_USER allocation only impluy __GFP_HARDWALL and that only makes difference for cpusets. It doesn't make difference in most cases though. > In fact, kernel allocations try so hard that we have those "opposite > flags" of ___GFP_NORETRY and ___GFP_RETRY_MAYFAIL because we often try > *TOO* hard, and reasonably many code-paths have that whole "let's > optimistically ask for a big allocation, but not try very hard and not > warn if it fails, because we can fall back on a smaller one". > > So it's _really_ hard to fail a small GFP_KERNEL allocation. It used > to be practically impossible, and in fact I think GFP_NOFAIL was > originally added long ago when the MM code was going through big > upheavals and one of the things that was mucked around with was the > whole "how hard to retry". There is a fundamental difference here. GPF_NOFAIL _guarantees_ that the allocation will not fail so callers do not check for the failure because they have (presumably) no (practical) way to handle the failure. -- Michal Hocko SUSE Labs