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 6550CC3DA4A for ; Thu, 22 Aug 2024 08:04:36 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id E8D4D6B0111; Thu, 22 Aug 2024 04:04:35 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id E3BF16B019D; Thu, 22 Aug 2024 04:04:35 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D03596B01A4; Thu, 22 Aug 2024 04:04:35 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id AE3D16B0111 for ; Thu, 22 Aug 2024 04:04:35 -0400 (EDT) Received: from smtpin09.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 3061C1C0B27 for ; Thu, 22 Aug 2024 08:04:35 +0000 (UTC) X-FDA: 82479144510.09.399C689 Received: from out30-100.freemail.mail.aliyun.com (out30-100.freemail.mail.aliyun.com [115.124.30.100]) by imf30.hostedemail.com (Postfix) with ESMTP id 224BA80022 for ; Thu, 22 Aug 2024 08:04:31 +0000 (UTC) Authentication-Results: imf30.hostedemail.com; dkim=pass header.d=linux.alibaba.com header.s=default header.b=SAUcgDGl; dmarc=pass (policy=none) header.from=linux.alibaba.com; spf=pass (imf30.hostedemail.com: domain of hsiangkao@linux.alibaba.com designates 115.124.30.100 as permitted sender) smtp.mailfrom=hsiangkao@linux.alibaba.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1724313814; a=rsa-sha256; cv=none; b=PWiSYvEkDJVW2NtUwmBKJeLAfCogpAk8TguJZM4AQGzf2SUHowHGl3eEad4V65uibg73nl IGXu5d/LxWOVDLgecVoIgCmGnPD1fD6uelqT5ccpagTCMgWLsbuu+GmdKyWelxLSFvhfJg Z3OUViFoSa+Jw1GwUFP5CcD3KtI5MPo= ARC-Authentication-Results: i=1; imf30.hostedemail.com; dkim=pass header.d=linux.alibaba.com header.s=default header.b=SAUcgDGl; dmarc=pass (policy=none) header.from=linux.alibaba.com; spf=pass (imf30.hostedemail.com: domain of hsiangkao@linux.alibaba.com designates 115.124.30.100 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=1724313814; 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=2BbQWat81tz/GQoQpQ9RvbaiG8gESqcNeLdTDdRv6ps=; b=iAXIKk7dVjZaUF59cuPJgTCq0tQQrgnE/luMCo/4WGi3c0KCN5DXVsogpnHlSi/tnR9YFr izTWOLmf2mMkr+4T9PYK4Ao8Pdn2Ml6UhHfP2L8CIjHlZ1DU3sTrx7L5GtbMz+4HPNyj1W oMvRLcU6gwRKaq+HdRV9gssCb8Iou24= DKIM-Signature:v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.alibaba.com; s=default; t=1724313868; h=Message-ID:Date:MIME-Version:Subject:To:From:Content-Type; bh=2BbQWat81tz/GQoQpQ9RvbaiG8gESqcNeLdTDdRv6ps=; b=SAUcgDGlPocIuJ30kn2vto6YjjKg2yBWA2USuVgaBEjLmT3Zqc6RX1S2XscY+fwab0kOquiAWk8AxaPZH13959iBctDCWWtVsqU99HY2shrCpeF/7ifzWwuNY4v7dATc+r7418SSohvf3Cm7McauCwwwjmXOv51EuWpqUcAley4= Received: from 30.221.130.46(mailfrom:hsiangkao@linux.alibaba.com fp:SMTPD_---0WDOMmTj_1724313866) by smtp.aliyun-inc.com; Thu, 22 Aug 2024 16:04:27 +0800 Message-ID: Date: Thu, 22 Aug 2024 16:04:25 +0800 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v3 0/4] mm: clarify nofail memory allocation To: Michal Hocko Cc: Linus Torvalds , 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> <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: 7bit X-Rspamd-Queue-Id: 224BA80022 X-Rspam-User: X-Rspamd-Server: rspam05 X-Stat-Signature: xgmmk6zw73qhhj566ktjd1sw1t83n9iz X-HE-Tag: 1724313871-684111 X-HE-Meta: U2FsdGVkX1/78g7/+kvTCV2XDVxxh1b2DjIAD+NCEzZp4IfEj7nJ7ly19Ly+Y+KO+8pf/BJoLZn41kfk1RQ5GwC5nQCxJ8hBfaRHJV/ksj3OUm1GrINSYndCvJhB8wUUf4b1W8YDxb1V1emfQIbAdedEyYj28ilt4OMAuVEvs+kLyQs1zaNTkbNin8LjcqsAmv+y6Dum6JJILf3vphXULci9HLGDjfGSE+Llswna6kvq91DIfz64mM+miN5pHGmkdcpXkQhdMjTox7Q4kmM0tUS+LhYXB5xfbRu9+nEiqW9UOwCEbErFNhQU/n//+EOOmI62x92Ho2sBnGGEsR1g+L3vSX+Ga9OPs0IJAPVDBud2bpz2ztHa6uzTi3tLL7Twhd98UxVgtb82ssRokYiIc+dVJESVJHNeaLmuzO0SjRMsBqOFUHgAp9so7jWrmpftz/Lij02F/qw8k7uIq6u2TfnF94+RasY03Enuv19qdScbtv4lQCJbHco3OkIGlsoapb1Byd4BZ4mCW1V23e2Ey46zeN1RQ1p+DJfWvQJ/2r7itKT3Q/Y3A29LIzGtkpxSshPt0r82mDt2nuiH+dA34J5GtizjoGlsb4gFwHZJbrVNr0719qFMCXTO8yEWsqWYMHakOVPF2MjrtTMdje1sLXSvJtKBnJNdv5nEbxNJRPO36vOV2LC9Sybaz/4mP7W47C6XBH8gDXQ9jyH+kSti0HQQRa4lUN+8gE9+T6Zlm+3WUFbZrZsmAoqvUDzAxnUKOuOPnibJ+bXkqWTQURw4J66M/qMHWD0wR4b96bKeE2GeCHGwZy0QhKUt7mo6vBx4DyIhTiWqQFrny135phIjeknflgTzdlXy/tg1oMJA+rzK4mDo8Y0pKJKTo23DEbnO8brYqJ8rqQ9lHNhDqy0/rF0Xw0FkQEFyOZUiQjRx9WoB1fB8dqLAiFXMTKRux4jr3W+o40MEyeZsxqlRM2u M13UwlmD +tzxhn7+qEQPFlcASr52C2jgsy+V4PmFyg14AVDx7ZYJKyMUZRSeOPF6ckK1dqYrUtaQXDyKX2CteuGFUpnScBBQ6MdnRMXak7y++dGw0xWfC5lD87TH9SERNj7Z0cEeKga8FA9nM9IS0Xk+AVH+6HVVRGdeMH0d5o0u+uDYN3/ZZqjU8icavF0kFvcjR78Ku9oEepU8CLo8mOPscxQkRa0bDpXyuKvHfv8KH4oXB/8RJ93Rq6Z+t4mzTNKrD9UUlAOBqYlKDjINsiUMrJj72DSYz49siAdsVG5Hcfv+gheshEm8= 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 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. > > And for PAGE_ALLOC_COSTLY_ORDER and NOFAIL at the page allocator level I > would argue that we do not want to provide such a strong guarantee to > anything order > 0. Just use kvmalloc for that purpose. Sure we > practically never fail up to costly order but guaranteeing that is a > different story. Agreed. Thanks, Gao Xiang >