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 6885AC3DA4A for ; Thu, 22 Aug 2024 09:11:24 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id E029A6B024F; Thu, 22 Aug 2024 05:11:22 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id DBF4D6B0250; Thu, 22 Aug 2024 05:11:22 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C033A6B0251; Thu, 22 Aug 2024 05:11:22 -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 A12076B024F for ; Thu, 22 Aug 2024 05:11:22 -0400 (EDT) Received: from smtpin16.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 57069C13F0 for ; Thu, 22 Aug 2024 09:11:22 +0000 (UTC) X-FDA: 82479312804.16.6F8E375 Received: from mail-ej1-f47.google.com (mail-ej1-f47.google.com [209.85.218.47]) by imf11.hostedemail.com (Postfix) with ESMTP id 51A6640005 for ; Thu, 22 Aug 2024 09:11:20 +0000 (UTC) Authentication-Results: imf11.hostedemail.com; dkim=pass header.d=suse.com header.s=google header.b=ChlxcJEw; spf=pass (imf11.hostedemail.com: domain of mhocko@suse.com designates 209.85.218.47 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=1724317839; a=rsa-sha256; cv=none; b=OOtXbdaBLFqlRBF4qIPz2NvV8NKfhwu6LTwKUyjH/jPMYOwbFSFajUBfxbtuOkIJNkMUyW /MaAlKoJbxFIMRJ/77ZvSQeNk6sraRN797tqsPtTOahvKeVozyy/5TY8B44m1V4501O7oi eE6olBc2n0Wd/SqzJ9H945y+dVYXBUY= ARC-Authentication-Results: i=1; imf11.hostedemail.com; dkim=pass header.d=suse.com header.s=google header.b=ChlxcJEw; spf=pass (imf11.hostedemail.com: domain of mhocko@suse.com designates 209.85.218.47 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=1724317839; 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=kZcVgOYl6gZrJKPQ2QEIwaOBVHmZVmxnqm/62ZXsEVQ=; b=myWGHRAP8+PYehOX/0jlKmrQDOns+0l1S6KVYWJYzrDkA9Vnd3fcTV+LIv0XdCDIVsdh3v kkOsFp0o3fhkiWECKDNzjIRsVhkOcv9O9p0fz4KUTBnlu+ZXd6J9cJjgxU0y69jfeCJDgg m+VLzVcmq2hqftn+08l6T36PVuZnXjU= Received: by mail-ej1-f47.google.com with SMTP id a640c23a62f3a-a8666734767so73021966b.1 for ; Thu, 22 Aug 2024 02:11:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1724317879; x=1724922679; 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=kZcVgOYl6gZrJKPQ2QEIwaOBVHmZVmxnqm/62ZXsEVQ=; b=ChlxcJEw7e3ALKvzgmQUg6wyoczmuUGMNsJKiDIzQpVuE473JXTSDI5R0zpPz0zW2L hbBjVdy816iGSNcekJDMG0AV7j4nPxZXNAEn/0jSefmFBvRlwP2DFEA985Beh5X1kzuY ss9mGRWaFNRXprHG03Na8giEKGSHmAay18D7rsr2lEqLo3AMNUHYqYFr/uTFwXVhaWIY f9t7F3gUxYwhR3QaJUhGE8d9+MEcR6/HLuEn2aY5/k6uC5VuXuad/KrIjixZZtvR1ehs e94afPk7UZpLIIytJAT+re+dAUy50ZaQez7XteVpewezxwpJ2tdt5qvzW6LVRWtJY82U Bl9A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1724317879; x=1724922679; 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=kZcVgOYl6gZrJKPQ2QEIwaOBVHmZVmxnqm/62ZXsEVQ=; b=dCniw6YtP1MEMUblaCNRxIbqUAfbqIskOp10zbG0GVlORRqN0NUm7WZzvvYUzKxZKv jB6J/4KmMxy/mAhvGVHDai28sCMZ3dbTQSVS6NcXbUnD4GgqGB2ny73E3vI2xy2ThMuJ GBQiNsyfes7P0HddzUCrHJ8L70Y+7hNsyptyDX3WL3+3s5SRbl7geGWloBJ5rM2anwSB c45m/Nu3oOwvVi7Fh57QYqAE/KTa8B01TQ+PxWM5pjDNsje28kX0WfYOFJBb2b6nqTb9 xncOL8T3Vif0pvXVqAh5rfDzfXvVBCJovo4mxlPzYb7iBsSgRSVrucIkBB5V75FXkX4M c+8w== X-Forwarded-Encrypted: i=1; AJvYcCW+f+jxP2Q5ccLPDTzdL9P9DIu2k3MiMzBFMb8Elwl8wtFybRj16z6yhx7toLmJ7j6oqF3Cqo3fEA==@kvack.org X-Gm-Message-State: AOJu0Yzvp9P8bSraOQ5qzC8QDDVQDy+Po+yV8kuLOKdTb8a1Ekh3mhOD cs2fHK+Jer4GixLWT3GpUcn6xPDv9gPPATdPqCxsf21LtCH7cucXdXF8GSYDCYM= X-Google-Smtp-Source: AGHT+IElpU86MA2dpTZSeUpiFFoaR8KAM7OcPhWJVoNF/ZYT8HlFRfKBxbWUdNXbxLRNqNsggYNm0Q== X-Received: by 2002:a17:907:7252:b0:a86:43c0:7d2 with SMTP id a640c23a62f3a-a866ee6476cmr448496766b.0.1724317878718; Thu, 22 Aug 2024 02:11:18 -0700 (PDT) Received: from localhost (109-81-92-13.rct.o2.cz. [109.81.92.13]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-a868f47c512sm88847366b.150.2024.08.22.02.11.18 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 22 Aug 2024 02:11:18 -0700 (PDT) Date: Thu, 22 Aug 2024 11:11:17 +0200 From: Michal Hocko To: David Hildenbrand Cc: Barry Song <21cnbao@gmail.com>, Linus Torvalds , 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-Stat-Signature: ipkk4hmrkebna4j6mxdbiowm9rt58eoi X-Rspamd-Queue-Id: 51A6640005 X-Rspam-User: X-Rspamd-Server: rspam10 X-HE-Tag: 1724317880-297908 X-HE-Meta: U2FsdGVkX18x8HH0blw7XIs3IDyxQGiwlurQj+FPYDvRuToA38msg58C5WLC4of4QExh4/FFgTHJ3mT0zcrkA7yciuY8nTfgE1g89yAHe3OHc8x8PI2ZLstE6LIoe26o9810PNdO2Hf9nMp3Gvxwz7jHfycvZoPru0doqUqXYQcadD9aaVWhYLl7aPCF1TWwT3pfsILyoMWrioQvzj7aBzervcyyP0nHEIfBeI/mNhCIeyI7tZnriOI4u8PuCA0VXrOHb5zSmCL9KNdKQWxlZuDGGN2Vqtx7Rd+eCwxJNU5HtCzBUVeV2tjlrHbFfqCJYS8q9w1RE2DVkzP2GfJBBhk4w27Xv/Ww1ZUjEQneIiTlOfWWeu4YVHbsUN6DzMzhfvIKdNL+5a/5d8HFyj0vn/oodrF1/5adQ9dgdocbN6AqC0eeNuw2NV6aXNTYxyOtwQTHWlvMq2SYtFgzEA2PBcrIZ813Vzm0UF+EPQ2PG3mGGbz8mxJ//Co9MCn/89yhamUXfb0KzF/7tatUTLIjuPnUWRDGDY4Q5gXP+jFDZ0HWYhz/t7HJ967MyVOPPxuAvF457uxvuKnYv5WZwSKBqnB13aIVD2HP+TnI5W7RRkAPP+f32bhy8ROzAZfFPWoMAW4uxd3sj/rYY5Rt2lYp/wSbgfZu/mIMtj20HqagP+vdd8fjs8es+vXdGfb/X3UtYp7AXbtkAoeO5RDLFh3Q8nH9Iz6HUhuPn3ehMatiQTZc4GQZr5h2dNShe+uGTf8ZKdPNdB60uLLfG/ofKN4wX9DNdNWWNK31uAfl3Z99/nMRhHNFKpt65MiEvuPo+YvyZhjuJvd5RrENKo1pAEvnnWyW7tRsaHqCQvmLfy31Ukb8++seMU0U+1j1ycTUM43mXTYP454n9FNwMy+mdWknclyltZrKxd5bqw5kPRAb8WKsyPj5uCoVe53IJdaeYBoEyrF4egYAeoMvZVSl/nH 3ZPHsiS5 5US8o/ZeSJZny5ADHOJD/0keRrsY3iEr6N0e8woqFud33ejXPUppWszS11Sa2Ct1vqoFma2XmZLy5DHrOG1b2IrREq0+VnPZ7O93nNtHMa9/0sZgux5DhOzxggagBGOEQ8CefGXv1gf+iJZB1dBrIAFMVJJ9+MxHmYqpknyT8DmCe8ASorX4Xzwo0A89033trA4bjLFeAAchY3q8IglIjT8xH3G44NwdtC/dIWviy9IEZKdIy52dHgN9J0Btw5oAFEpkd+HoUWZXme8+vGuhZREvR0gWixM77YD7ZzNaqo2A197oi+/8nXW4Nrme+wxboOZFOFRYNp0RVvXxcOkgpsz3glxPtbIdQ2S2PZWz/C+vtZck= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000068, 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 10:39:09, David Hildenbrand wrote: [...] > But then the question is: does it really make sense to differentiate > difference between an NOFAIL allocation under memory pressure of MAX_ORDER > compared to MAX_ORDER+1 (Linus also touched on that)? It could well take > minutes/hours/days to satisfy a very large NOFAIL allocation. So callers > should be prepared to run into effective lockups ... :/ As pointed out in other subthread. We shouldn't really pretend we support NOFAIL for order > 0, or at least anything > A_SMALL_ORDER and encourage kvmalloc for those users. A nofail order 2 allocation can kill most of the userspace on terribly fragmented system that is kernel allocation heavy. > NOFAIL shouldn't exist, or at least not used to that degree. Let's put whishful thinking aside. Unless somebody manages to go over all existing NOFAIL users and fix them then we should better focus on providing a reasonable clearly documented and enforced semantic. -- Michal Hocko SUSE Labs