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 45EEAC3DA4A for ; Thu, 22 Aug 2024 15:03:12 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 748156B026E; Thu, 22 Aug 2024 11:03:11 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 6D0866B0271; Thu, 22 Aug 2024 11:03:11 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 570806B026F; Thu, 22 Aug 2024 11:03:11 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 39C0C6B026B for ; Thu, 22 Aug 2024 11:03:11 -0400 (EDT) Received: from smtpin01.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 933081A17AB for ; Thu, 22 Aug 2024 15:03:10 +0000 (UTC) X-FDA: 82480199340.01.72C49FA Received: from out30-101.freemail.mail.aliyun.com (out30-101.freemail.mail.aliyun.com [115.124.30.101]) by imf21.hostedemail.com (Postfix) with ESMTP id 8670B1C006E for ; Thu, 22 Aug 2024 15:02:53 +0000 (UTC) Authentication-Results: imf21.hostedemail.com; dkim=pass header.d=linux.alibaba.com header.s=default header.b=k3J4yYl0; dmarc=pass (policy=none) header.from=linux.alibaba.com; spf=pass (imf21.hostedemail.com: domain of hsiangkao@linux.alibaba.com designates 115.124.30.101 as permitted sender) smtp.mailfrom=hsiangkao@linux.alibaba.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1724338959; a=rsa-sha256; cv=none; b=aEgwcoHygqui/hOnss0hK573wOdpEi/MUM61We/1foca9zRmAgYCbNLTC3GbDLWB4BEGzK 8TC5/xHHx+kD4dzPn3pw8SrqrC+eWz1xhFJA/jnjvi7Y9P2vbOoe/cobya9Kd9yfk6DQqN eorjK5TjNxsunHMAFTmXLDfWVvarg5Y= ARC-Authentication-Results: i=1; imf21.hostedemail.com; dkim=pass header.d=linux.alibaba.com header.s=default header.b=k3J4yYl0; dmarc=pass (policy=none) header.from=linux.alibaba.com; spf=pass (imf21.hostedemail.com: domain of hsiangkao@linux.alibaba.com designates 115.124.30.101 as permitted sender) smtp.mailfrom=hsiangkao@linux.alibaba.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1724338959; 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=peTEqBgOuAT8bs3zeMz5eUMcF0EAlNt2QLgLaqnO5Gs=; b=N9qwKxVIq5X72aXZjg0esMiiBlhcIgO5tjJRj50f+oO9PseF1N/X9ZiI8wXhvXzOU/hAY7 PCdf2yrsM/CdB2VQFYVgUOmibp1HuzxB0YRtDlgRe/ZCrO2NrmB6mtdLA5YAJX9mA69U3L oUzQBpKZVeFnH+5rzHYRZK7MyVp063U= DKIM-Signature:v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.alibaba.com; s=default; t=1724338970; h=Message-ID:Date:MIME-Version:Subject:To:From:Content-Type; bh=peTEqBgOuAT8bs3zeMz5eUMcF0EAlNt2QLgLaqnO5Gs=; b=k3J4yYl0jyNbdE6ZqmLyJy9lSb2Cb8hHim11j/e0Tw+jSskjNRkqPJQeh9pmuj3QFXshTDPigK8SUuuIw0re7PVfLmo7BYCFDFjtmRMXjrq2mcXqSjpfO0KpMYFJZe+XrAmR/JOGG5070+ACC/vIvhn8CeucH5Gbbfr/67RvcyA= Received: from 192.168.2.4(mailfrom:hsiangkao@linux.alibaba.com fp:SMTPD_---0WDQjJbl_1724338966) by smtp.aliyun-inc.com; Thu, 22 Aug 2024 23:02:48 +0800 Message-ID: Date: Thu, 22 Aug 2024 23:02:46 +0800 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v3 0/4] mm: clarify nofail memory allocation To: Yafang Shao Cc: Michal Hocko , Linus Torvalds , David Hildenbrand , Barry Song <21cnbao@gmail.com>, 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 References: <20240817062449.21164-1-21cnbao@gmail.com> <7050deab-e99c-4c83-b7b9-b5dad42f4e95@redhat.com> <9fa8eca0-ad4e-445c-a21e-aaabb6aa4160@linux.alibaba.com> From: Gao Xiang In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Rspam-User: X-Rspamd-Queue-Id: 8670B1C006E X-Rspamd-Server: rspam01 X-Stat-Signature: 61e93c1tbhnwrctoaiekx1enhjcyxhjx X-HE-Tag: 1724338973-321573 X-HE-Meta: U2FsdGVkX185VDwRCzQBkGqRKxSzT2bi8RZpuqldj/Nv/Vjl7X4H4nLP8tSkjJVFcnB+bKsM8BgVTDvEYbwF2hKPTwXnj4RdO8uNwuJIs0UVmvPSj+/R0+mvTt7G+BMDQ5Gx12RkKqvEFzA3BHE0egPywhZWlkZE0DFcY2mr93GvGIKlfUAdHe5GvAq87adY8rHu0DVla9Yt87Xln/RpbW3XMQurXl9pQ+0zzAmlH1N+PoSJWwXm9YjVCUWVn5hQYLlHWdsemdvzPH4LG8+QvZevuZfuT1c2bHIHHJGKEKPrRl5Fp2EfiJgq/jFl9FpsgWZUcxHOXo2oZy+Ee6S81L8gXzFN7jn25x7eLk41NJ4U8xy/ZQYAaeaLp191FdA0WOaMrASDl7cqmMjLsYj3LLp5TxMK7jpL8lPMnoD6cp2wYhALm89n6XG3W0PMNFCzvJxicPRPskdFPXRvpeci9G0/FzlRMqNMO1zUCptls7O2f9IxikUeevZ3G7U84R+9l8LoPUiO0D8Z4puaWCAu35HHY/NcmHo1FSRXTqtr5nqdv2qghJ7ynEQPtKu/sBodPGFNdZOT9vVksczjyQ+X+vLXh2xnHR27ZT9txg0l5gnRDA33bBJXV/R7q02qlr3aWWWNYQ/r68Jpnhar016uOmVp0tPnd55tHIdqLcB52XYcsGIWfLIhc4zQngtqLqRVNKFARsY+P6VnUeDOwcf7nnCoZmSEAy4FSE3VfejPr6MyI2raSJhuDTjk3Sd+cXHRf5lxa8DmLFI5vRd6oup5ib3Z03FBdVAb6wiEHpn4qtkI2uO9Buk4LGpwEYcR6kP+wbt+DktXQ93fEjhMdBAfrkAABlAiSVhI/hO+FigJKevliYKJxUgEYTLn0fiYk7R+i1OzfWSoCqZidRajVLvmiKhOXvoCK/0ZlY1uHPIBqdgOww85BMGSG9KrVIJga41LUOTBam/sSbBaIyepDeD HBlYiP5/ yM3UiaydL3HdM27duQjGFFJw0CWVPuE9K5dquD1/V1yDoCO59Zl73BwCzUfAyRQtWxfOwy09XXyZHovIsjfrvyvYvOyZZ16lYPl7eXxjM0IFm4hGCmNmZhEtnV6F6WiDErlJJrDo57wMHnIa9FyB9ioDe3MiUfBHfY/2SMYuUGJnsWK99l7Ije4f4m7JfHEA8kS8r0MSquRzgztnUw+6lIM1gzlPehfBSBlPp26SUZ6e30q7MS98sfCUa6yCTCYod+Bwruey/I59qsMYCr2e/HmNso8QGzIYNHyJkRpFHm2M65jYlXLR7WZZ0wQvAHbMwgysPrYBflraH65zvo5WUYuTxaGXhXyIjoSR5Oe7NuWXiP3PAVdEkBrXexSz2zhGBi43kiqNF8rNc7KQ1XgyxwIoZGlyNd2NnicAd 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 2024/8/22 22:35, Yafang Shao wrote: > On Thu, Aug 22, 2024 at 4:04 PM Gao Xiang wrote: >> >> Hi Michal, >> >> On 2024/8/22 15:54, Michal Hocko wrote: >>> On Thu 22-08-24 15:01:43, Gao Xiang wrote: >>>> In my opinion, I'm not sure how PAGE_ALLOC_COSTLY_ORDER restriction >>>> means for a single shot. Because assume even if you don't consider >>>> a virtual consecutive buffer, people could also do >>>> < PAGE_ALLOC_COSTLY_ORDER allocations multiple times to get almost >>>> the same heavy workload to the whole system. And we also allow >>>> direct/kswap reclaim here. >>> >>> Quite honestly I do not think that PAGE_ALLOC_COSTLY_ORDER constrain >>> make sense outside of the page allocator proper. There is no reason why >>> vmalloc NOFAIL should be constrained by that. Sure it should be >>> contrained to some value but considering it is just a bunch of PAGE_SIZE >>> allocation then the limit could be higher. I am not sure where the >>> practical limit should be but anything that requires more than couple of >>> MBs seems really excessive. >> >> Yeah, totally agreed, that would make my own life easier, of >> course I will not allocate MBs insanely. >> >> I've always trying to kill unnecessary NOFAILs (mostly together >> with code cleanups), but if a failure path increases more than >> 100 LOCs just for rare failure and extreme workloads, I _do_ >> hope kvmalloc(NOFAIL) could work instead. > > If the LOCs in the error handler are a concern, I believe we can > simplify it to a single line: while (!alloc()), which is essentially > what NOFAIL does and is also the reason we want desperate NOFAIL. > > A better approach might involve failing after a maximum number of > retries at the call site, for example: > > while (try < max_retries && !alloc()) > > At least that is better than the endless loop in the page allocator. Funny. Thanks, Gao Xiang