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 E657DC3DA4A for ; Thu, 22 Aug 2024 14:36:32 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 4EF2F80030; Thu, 22 Aug 2024 10:36:32 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 4A0158001E; Thu, 22 Aug 2024 10:36:32 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 3419E80030; Thu, 22 Aug 2024 10:36:32 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id 144108001E for ; Thu, 22 Aug 2024 10:36:32 -0400 (EDT) Received: from smtpin20.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id AF9971A163C for ; Thu, 22 Aug 2024 14:36:31 +0000 (UTC) X-FDA: 82480132182.20.A92A4B8 Received: from mail-oo1-f49.google.com (mail-oo1-f49.google.com [209.85.161.49]) by imf21.hostedemail.com (Postfix) with ESMTP id EA5171C0018 for ; Thu, 22 Aug 2024 14:36:29 +0000 (UTC) Authentication-Results: imf21.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=b2e7oaBC; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf21.hostedemail.com: domain of laoar.shao@gmail.com designates 209.85.161.49 as permitted sender) smtp.mailfrom=laoar.shao@gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1724337373; a=rsa-sha256; cv=none; b=lutZ3pmBmtCJ9WXVqtK6fOM80mGl+gbTUYhKrrsfs42nn1ob6t/Mw/qjY9HGWhs5t81b4Y xFnXgDRa5X2zP/qBjX77jgszZSqJ+2FSWeWeuxtooes/PzZ/EsmcMA5tNJATayzMoc5Mxp I7s0QXUFcfnNOpd04Mbadm9YNKRpR88= ARC-Authentication-Results: i=1; imf21.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=b2e7oaBC; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf21.hostedemail.com: domain of laoar.shao@gmail.com designates 209.85.161.49 as permitted sender) smtp.mailfrom=laoar.shao@gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1724337373; 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=3BbnC8t2PJTnIbX+3XWfmLQvDXGHfT/Qc+/o6DnBM8k=; b=Hs8nZ0tDFNVmHxrnoHqHCl1DWeTlSaKFGvjQgeJo3N7lKhKOFLjZqmbWvdATH3IHjyYN6B 2iq3c8aL18y0nK+7utIYOj9a2mFfq/5iW5p47JVG5UQTMGG2aIbCuGyA1LMKB9JVs7FB47 egqSJaHAm4Jgym7NmwDjzvYYBOpWZsU= Received: by mail-oo1-f49.google.com with SMTP id 006d021491bc7-5dca9cc71b2so597890eaf.2 for ; Thu, 22 Aug 2024 07:36:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1724337389; x=1724942189; darn=kvack.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=3BbnC8t2PJTnIbX+3XWfmLQvDXGHfT/Qc+/o6DnBM8k=; b=b2e7oaBC8A6V/LwjpkNgOavsOKz8diVHgUoNZQueVmhpIyEQ439P6wRw8h9E/vN/NH AO+hpQ1Zm6YUOV1PJ7K1/PNgMgRQqy2teEbz4RCz+OSF05nMHd/cM9Lx8I8ZeJOqov+g uis6U6u6uKt5V95bZfOsSpC9l/Q7TNbSPqMmiCEhJdB8RL94K1DPvSL/SS9nO7UU4T+O M6KS1L244xU/ZJOyaSNyl7Taw5TVWMQKykBmmwj3V7X7bDAo/ujxX8XeuEiePXKO8lc/ UaWy7FcQvt603pg6yTB9qoRixWed1X7SAc0EWRJvwUqEJCzDiZYHQSXiKgr2Vbt7XBwx j/Dw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1724337389; x=1724942189; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=3BbnC8t2PJTnIbX+3XWfmLQvDXGHfT/Qc+/o6DnBM8k=; b=wfe/buXGkmbFQgubMSWnACPZg5Bf4UTR5sIXWjqCubRW4l67IrxYUjAWxNaVM7PZJI 3+nI9MN8NxmifWGZG8EQNshHs7EUpKbz5I7yNx67W4HDs/fz9h/sxtepAydN4H65BHgS O4QgMKAZc+VCINY80o0NarCA6gUxb9W3wmUzbHitEpIAfr9kkjDRGXil7HfYYmVhwa1A wrqlLe3xi29DPk6cG03lgMjhJ8k76fQiLB5gUYSso6OvgaTgqeaY0i9SuiWBhVVZER65 zLMc2eYg2cr7sgu5d9b3cARdCLhr59e/xhX4RCqD35CifmbkmPY/+RhbnXvrPU/K8Xhh 9GmQ== X-Forwarded-Encrypted: i=1; AJvYcCUB+lE9ijkpVA7fnbJIoZQ+Q7WWFzK+fxHWnrO6NXnxFfZgUeYHL2jRtau8lWv2vKMaMivXybpBNQ==@kvack.org X-Gm-Message-State: AOJu0Ywgjfv67QKoAgY/Ch0MLb23CYF6nogKZ6yag/tTbMGJF/ge3qtw aoENH5TSGM8FYKz/iJN1S8gz8zY+MByymzPK7kGnGSjOb8gfosmTJgeMzPcumZGjBSBl5yBDgYw FgY+NzqQoVEKheKvoU68spd4E3T0= X-Google-Smtp-Source: AGHT+IHWMxdwUMfLtf5zUA8aXZE4o5FfBDVwPtGUufuYCxo0BWl8ikb5XZ4xY7aL7CHeRE7eIyKQ1fqp6MKADgra/No= X-Received: by 2002:a05:6820:220a:b0:5d8:f3f:b1f7 with SMTP id 006d021491bc7-5dca0648d97mr6666875eaf.6.1724337388886; Thu, 22 Aug 2024 07:36:28 -0700 (PDT) MIME-Version: 1.0 References: <20240817062449.21164-1-21cnbao@gmail.com> <7050deab-e99c-4c83-b7b9-b5dad42f4e95@redhat.com> <9fa8eca0-ad4e-445c-a21e-aaabb6aa4160@linux.alibaba.com> In-Reply-To: From: Yafang Shao Date: Thu, 22 Aug 2024 22:35:50 +0800 Message-ID: Subject: Re: [PATCH v3 0/4] mm: clarify nofail memory allocation To: Gao Xiang 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 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspam-User: X-Rspamd-Queue-Id: EA5171C0018 X-Rspamd-Server: rspam01 X-Stat-Signature: jsbw9p5grqgs3qdcyo519ot7yoowf8zd X-HE-Tag: 1724337389-550637 X-HE-Meta: U2FsdGVkX18GaTTU7d7mJMmcUNAgHrYwfYerC0ULHGRo8d9H7ri5XvmKvFz02wCAL1NMpb9fodvk2d18YdubcDRZb10dFAHCUiPFVAljYA1TktFc5L6nQcIgTH/z1Quwlk9sMjRMUZptQ+bpUCID9GnVqqiaiBnitrc2hv50wrZKAvdl4t1/7P9AeZ/JRR9igLjbxakNb/7lRL+poxr6BGmFslqlOqn7M2tl7kdwGUsCGs8Pp9H3ljhuCSiKiebAtYHj/RUina205zNPhImTjOVcWNPbvXOF6kk+hPcrTZZZRKOu3rycm9WEwTC1Zsq9Le/mKD5inaLFsHQ/comI7Mlrh1yRFsoTQhrXIC/DrxIQHadMlayUTCgbYJIi9+LVhQWHJqwLBFHgRwH8pIar82XV47QQXnfFOrZpsn/3Y0db469GRS7AllA3CxK9oob99krYQOIZAkQOHZ/caXSNRSpfUU+PIndtfT8Lt+npXXkEk9J1yeCZz+zgkBFaxsPIpFaj9iIUBYslvEnb3MLLC8xareJ5M33wM9apjJVqBbY2keM2Ue0zOCMb+Lz3O+XB77ULyRnxJXUjCUJmxyGxzOZKXHmkmOcREUFsMwVj0h1ZqomRB5eibyX6HObMFM/B2TuQam8yUxuUNJE2eae/mgWJzWbq+cneb3pvliTnAHFGW1wr9Y3BqpD9fnPeJRdNBaXeAYVVjdjmPnYZSGejGHWukBFySv4Bx7v+VjcDzaujSAZZAD+SAOgZJwBcSf5oXmi7hFlBsbWMJnDO4IlaX6Tyswx6Efmz3D5OKaeaTGwXa8KSv4JSw3xCEL9bQ5OSWPMTbChhevUYmVXGeR4DHGBX1AxZmzAY2QXZw2cGGzeG0b6/kKUzdor4fqATiwM+Snxq1+hNOs5ktdA3gMDFibehliO908qzzIJPLbEgrB5OQ2Tn4soYbK7RDOgkVKS0Fq2UsuIWY9bV+iBt1HN EcmUipXu bolNeeT7h1zMfj6950O4VVBIerY2jWmqW2vaONDctzbNTXtbVqCnY/iN7pQdo+f3igwiZIZbs2Nkn2BfZ6R5w7vD1wLdR7B/FSDOnAgpfe8eQ2sl6XTtx4C9EiEpWzFzA8dRwJAqXa+EdEsLysczyTwML4tOEGkcKlrB/EyOOXASiSH61ULWA4Whlb8eX7E0UEaFQoNBZitZIerx9Wwco9red+HqFnl5boAD4RZBIZH02uJtqVGseK9xNhv4QOS1R5USLEw+/BPCGvs6xjqrC/E1ttKDYZPR+L5OPsSNJg2qc3s6c48iv6BKrbHaGSjJ5ya4W4JkZFnin+LYugjn3gQcGKeDYC+c8iBbzq+KUr04vWhSrg1a5ksTcx0Q5uiKArCe5wGDZogRxlULPAjWm5tzHGALRDFB0Nqf8wa/GzGhLmJ8= 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, Aug 22, 2024 at 4:04=E2=80=AFPM 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_SIZ= E > > allocation then the limit could be higher. I am not sure where the > > practical limit should be but anything that requires more than couple o= f > > 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. --=20 Regards Yafang