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 A403BC3DA4A for ; Thu, 22 Aug 2024 07:01:55 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 20D958000B; Thu, 22 Aug 2024 03:01:55 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 196E080009; Thu, 22 Aug 2024 03:01:55 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 036308000B; Thu, 22 Aug 2024 03:01:54 -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 D677580009 for ; Thu, 22 Aug 2024 03:01:54 -0400 (EDT) Received: from smtpin17.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 928F21C4E4C for ; Thu, 22 Aug 2024 07:01:54 +0000 (UTC) X-FDA: 82478986548.17.92F526E Received: from out30-111.freemail.mail.aliyun.com (out30-111.freemail.mail.aliyun.com [115.124.30.111]) by imf02.hostedemail.com (Postfix) with ESMTP id 296BB80011 for ; Thu, 22 Aug 2024 07:01:50 +0000 (UTC) Authentication-Results: imf02.hostedemail.com; dkim=pass header.d=linux.alibaba.com header.s=default header.b=DCWyk5xq; dmarc=pass (policy=none) header.from=linux.alibaba.com; spf=pass (imf02.hostedemail.com: domain of hsiangkao@linux.alibaba.com designates 115.124.30.111 as permitted sender) smtp.mailfrom=hsiangkao@linux.alibaba.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1724310046; a=rsa-sha256; cv=none; b=YUmAu8t3GvyaRoVYb6hb3x7Dn4tKzdlGP5PiqPPIddB7IXF1QsVUFAr3V1Y0/0QO0yBnLp TAA2XDhvBJ8D8Q7eYtBGjRHjIJFvK/Pl1QViIs+EM/llxTUEgmUHtEG6L9O3ViLysm1NZZ jTa69+bl/8zYdV8a8a7v9N6w9cCGTQU= ARC-Authentication-Results: i=1; imf02.hostedemail.com; dkim=pass header.d=linux.alibaba.com header.s=default header.b=DCWyk5xq; dmarc=pass (policy=none) header.from=linux.alibaba.com; spf=pass (imf02.hostedemail.com: domain of hsiangkao@linux.alibaba.com designates 115.124.30.111 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=1724310046; 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=N2fEU+06lguC78zu1nUxZMhGeMq6Xm3dBHYAYYSq9a4=; b=08weCZEUDNC23kKAxeCemmJxcr7Q7tK9ej0dJ+izxyk+hcmQ/0MwevKmPheh0VOoRonjR2 ZlaoyA2Il1CbsKi7hagR7DdrwjPYf5Z9MK0Df/INXiHZBmqNjzwd0A2bilTvzmuH3dK47w TKOuzbRBCXHsP1+Y8DP86RqbqKC36Ck= DKIM-Signature:v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.alibaba.com; s=default; t=1724310107; h=Message-ID:Date:MIME-Version:Subject:To:From:Content-Type; bh=N2fEU+06lguC78zu1nUxZMhGeMq6Xm3dBHYAYYSq9a4=; b=DCWyk5xqzwtUc1MOel7DPuGO9azij1L+jz4quiMPvWF5EDqWaa++zuQncg8lHntA6C3CfNKECarnLB8FlmXGZKeGwN0Fa69RgZpcRMsR7wcWsh1Q7SrAshi9bvTJSdzcDi3iRcaancegI7xFI8CcGVY10NMwURbNztBEO941b5w= Received: from 30.221.130.46(mailfrom:hsiangkao@linux.alibaba.com fp:SMTPD_---0WDOC3sx_1724310104) by smtp.aliyun-inc.com; Thu, 22 Aug 2024 15:01:45 +0800 Message-ID: <9fa8eca0-ad4e-445c-a21e-aaabb6aa4160@linux.alibaba.com> Date: Thu, 22 Aug 2024 15:01:43 +0800 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v3 0/4] mm: clarify nofail memory allocation To: Linus Torvalds , Michal Hocko Cc: Yafang Shao , 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> From: Gao Xiang In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Server: rspam12 X-Rspamd-Queue-Id: 296BB80011 X-Stat-Signature: jemj1yircqzzauoyo169gmxhmq1iekpg X-Rspam-User: X-HE-Tag: 1724310110-578183 X-HE-Meta: U2FsdGVkX19Lq6/fnLMkZ7SnRiNxn8KCJ40KPEoDLncr1Ma3S3cSzpO9nOF0d/Ul7OiAZx5Wc+6fmnCSecZoLNLJhY6cnzdoWG+8VgsZXmxX9FVegIqFUDtNe7VX0ZoPIZDRS7BKnh5rVBKDYqn9G7d6j1anZWFd0CuTljMMXTvKU+8i5hrvSigF9/8FgezB6NCWeKeBrfPkyO44HFB91f070l+OGTtesudcxsozJri1EIp+nSd/hA8z3DVlnnXCPfeS+qb3w/7GywVOugyUIHetWDmBnK4ZLpBbArdQl+VuyijHlkOj6FEWpz+Ow7sgCJwOIfr2KwsnM0lGX/Dw7g3rtUVxUbd7FLpqXvSZcrwALBJk6Fsgg0fokIfoAR/zt7iGnRDKOo6K36Ctj0hYqKJ2bMLeO62PrGrObNfQCCvLL13b+1lJZG7VRbGruJV0VSW6/VIeMJmxPKU5fSWWKlI9RHKho/p2CswOfAUsPlsco8hTcdUQc6klA4syLVmkFRTNY/lVgrqb76TV4P1bgllKZUggJGpKmDQ42zjWSZSTSSRYSNPP4lQ0Wr2RzpY6L3709NGjUuK1QDjO2QsFjdxgdYpJkHVrxXrRIVaEXoNLuPA3SPs/1HjiRId1tZPjFoncqkePPlfSoeg9oprooGu1PgT0mBpm3KVIv+5oc3VTSDo4Re8zbdzcKFihtz0LGseasqIydXKwwA552bYVxLRL9PR6I9t5trmCM1t6FN50o4pbNFR6wVi6y7jM7dbwMOShF3ajBOKUUcb2XKUA/NxtAIJitQKuu4UvsLa+4/FPimDGbVVyocoHPFYlR3XIEl/1BVP/iIcv1g1RzK7udTekrDAkiu4Qit8mWQtqmmX3UXGFIr1/8DQXgmlgjS7J5i4OKwQmJ/eZOvz053o6GCadtQU1MiIC9hXOC7P7hj0iB05EwpXCNbC/qNzHeiqE8/ikDus/SGgVEUB8jJd 96oKFS2C ohqB3CWTbZ1ImtA3JvffXe5cxc1HkGDgv6zBPt6Kihkm5S50dUCBA9Towe3wOvrG0/ipSCFV9+8ZeaWmVI2pCS4oSG4npb3VOGclpExuaHe30SXWqufVNeiO2MrrgzisMriR0CXL9UrAneXBhqTV+CfTuB7ji/3w+SdvBCrMp6dIYL+Q2TRoetrQivcxn1UfR5RfDallGnV2KT7/zDJnezRfhfVcMP3yy3PE9Q/5DbAKg8Ac/0BfRtXoyIi+mrHHRwI+K4Fd2Fg1uy06QFonDM1RT8ymiFmFjaeRFq47xzE+O4pRbCWX5Klo7HEwYG++oFW8f/+0jJ9uUlYzHzIxpx8K8zMimW6YIn3r8Pwh1KXOfxnyOZr+YoMbeMR2x9T60k3HE9bzRMALfWuEMx5eSMrbuF2dGnfiMn097COS5NOdvXhwAQTSggB4ZKxe6k32vMP9z 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: Hi Linus, On 2024/8/22 14:40, Linus Torvalds wrote: > On Thu, 22 Aug 2024 at 14:21, Michal Hocko wrote: >> >> The reality disagrees because there is a real demand for real GFP_NOFAIL >> semantic. By that I do not mean arbitrary requests and sure GFP_NOFAIL >> for higher orders is really hard to achieve but kvmalloc GFP_NOFAIL for >> anything larger than PAGE_SIZE is doable without a considerable burden >> on the MM end. > > Doable? Sure. Sensible? Not clear. > > I do not find a single case of that in the kernel. > > I did find three cases of kvcalloc(NOFAIL) in the nouveau driver and > one in erofs. It's not clear that any of them make much sense (or that > the erofs one is actually a large allocation). I don't follow all the thread due to other internal work ongoing but EROFS could do _large_ kvmalloc NOFAIL allocation according to PAGE_ALLOC_COSTLY_ORDER (~24kb at most due to on-disk restriction), my detailed story was outlined in my previous reply (and thread): https://lore.kernel.org/r/20d782ad-c059-4029-9c75-0ef278c98d81@linux.alibaba.com Because EROFS needs page arraies for vmap and then do decompression, for the worst case, it almost needs ~24kb temporary page array but that is the end user choice to use such extreme compression (mostly just syzkallar crafted images.) 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. Failure path is complex in some cases like here and it's hard to reach or get it right. If kvmalloc() will be restricted on < PAGE_ALLOC_COSTLY_ORDER anyway, I guess I will use a global static buffer (and a sleeping lock) as a worst fallback to fulfill the extreme on-disk restriction. Thanks, Gao Xiang