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 84D56C3DA4A for ; Thu, 22 Aug 2024 09:33:27 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 137556B01A2; Thu, 22 Aug 2024 05:33:27 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 0E7696B01A3; Thu, 22 Aug 2024 05:33:27 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id EA2E06B01A4; Thu, 22 Aug 2024 05:33:26 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id C9B7D6B01A2 for ; Thu, 22 Aug 2024 05:33:26 -0400 (EDT) Received: from smtpin10.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 6F6B2C1389 for ; Thu, 22 Aug 2024 09:33:26 +0000 (UTC) X-FDA: 82479368412.10.B7EF5D6 Received: from mail-ej1-f47.google.com (mail-ej1-f47.google.com [209.85.218.47]) by imf04.hostedemail.com (Postfix) with ESMTP id 72DA240020 for ; Thu, 22 Aug 2024 09:33:24 +0000 (UTC) Authentication-Results: imf04.hostedemail.com; dkim=pass header.d=suse.com header.s=google header.b=EOxV77mW; spf=pass (imf04.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=1724319097; 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=vtpOHRbTf2cL1AHUBxa7KAcuYN0LHvUciD3+K4T1tMM=; b=qasKXMEc32a2qeaPpKv3uYXRnxrGhu7K8DJ9XZZjokf2FA1uaROpIUnlfJLP/3tSMFm0ET zIRsql6m4IrxxpFr7x7LhxmGc4eIzKZOHuGt3YZY/orpNfmyqgHPQ6on7EDS1HXbV2Sa6k 1/ROqlsfpdL9DgkJoYGmENXPEO69leA= ARC-Authentication-Results: i=1; imf04.hostedemail.com; dkim=pass header.d=suse.com header.s=google header.b=EOxV77mW; spf=pass (imf04.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=1724319097; a=rsa-sha256; cv=none; b=tf1Aryq5dn8zUU/j9iBodBbnPi3l+JxcOaSc7Ze6TBx3gphPJ41tG1A5B4ojfZaVSd7t/r 5Qd82KokCBh+Ln3ad97egR1majxsnWljy1DxjfkOnY6CO1alo6ls+PbdcqzL11mO4Bk2B4 77r+Yx5ro8KNvAR6xH6JaA8rbkx2PEY= Received: by mail-ej1-f47.google.com with SMTP id a640c23a62f3a-a8682bb5e79so87080166b.2 for ; Thu, 22 Aug 2024 02:33:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1724319203; x=1724924003; 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=vtpOHRbTf2cL1AHUBxa7KAcuYN0LHvUciD3+K4T1tMM=; b=EOxV77mWh5G/0XGGOZd1cpVSf2M5DmwhlU0kK0PYHrhUT+TFhGAhgmNN4KSiErmDsu qfy+Ytc2i95morrXjfwhdX0jnsGWPrt+EJsK8Limkw/GmBX5PwOfSyN+NaGb4LecLbdT mXkBPUflsosPt8NUD//WhlFcn/fpllggRWVc92wXWDwpO/fdNtVvpyfrckPgL46CwfCT cu8far0KTlF/WmItRItAasAaRQv0k+j/x+jw2nhRAiSrPkQWSN1AYJ2GDvukUrrPihNT BvWBG7aMIyq6EaMXAnMkRUh5vadYr9wc8lKKZ9mkmOiPnPrd2sXBq92tgJHzKTR9yviJ 1Jmg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1724319203; x=1724924003; 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=vtpOHRbTf2cL1AHUBxa7KAcuYN0LHvUciD3+K4T1tMM=; b=leZINLYktyC7i5LCCLSXN65EYqeGnw+ODoK2PhZOLas96Cc54bo/QbFkndocWKrQHB fADqk7+w0eSZOuPAG8hcEJdjGKMgd20td7iSXmoCF9BgZHb/KWKlA+WfH5bO2obr4qnR 18342xBpH3LveDeqinG/D6Urt3/f0YMLzZm3Cq7mMo8liOgLWNt72ARGmkyNi1f1iG8u +wo6fbparO9JPc/SOSIIsCCS0LCGIKB3ozfTPnpgHt5MXemzctnwmpEBhUI+fCPiJdge g+2w7ITeApSiuQ5DAqtHsxcatzz0+82IZZfuPIHB4r7usWYFwtjhs1B35BDAhkwX2C9v QtNg== X-Forwarded-Encrypted: i=1; AJvYcCW2l5QrtPygSZzCYFHdm5/FNxy9/oP0sGjguSf6DlnZBqmgwxGbTOjWNDWWdkMf1dnMaX0ErYtP4g==@kvack.org X-Gm-Message-State: AOJu0YwHfl8Z0RRXAB++c2+khgfQNu0YoAh2VO6oLXivjhUawUD7hlpS YFiW6Y4BWR3j+4oPitEM6d3a718qD+l3P+qyWtBmSCWfcVxq6o7weVlF4OfKawc= X-Google-Smtp-Source: AGHT+IGYiLDhYoQ/9N0KZs1sCSGFDOIiE0Js1DYKhz/qTr/auLcTrLYgfMfybD6M2Ouq1lkQ3/1eaA== X-Received: by 2002:a17:907:3d89:b0:a77:db36:1ccf with SMTP id a640c23a62f3a-a866f8f0692mr318504066b.42.1724319202777; Thu, 22 Aug 2024 02:33:22 -0700 (PDT) Received: from localhost (109-81-92-13.rct.o2.cz. [109.81.92.13]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-a868f4378f3sm92315366b.132.2024.08.22.02.33.22 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 22 Aug 2024 02:33:22 -0700 (PDT) Date: Thu, 22 Aug 2024 11:33:21 +0200 From: Michal Hocko To: Linus Torvalds Cc: David Hildenbrand , Barry Song <21cnbao@gmail.com>, 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-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: 72DA240020 X-Stat-Signature: zj8q6pj8w3uwyrre4zkt45tqw9eqiwaq X-Rspam-User: X-HE-Tag: 1724319204-332986 X-HE-Meta: U2FsdGVkX19k8SGinOlU95xcoQlpTrmQ0OTIlINmg5Qd6GPnhZ5jo+l8T/fk+jaCyf0v1QoEYI7yep9yGXb5ABLcnxM8oYWDpAcGzmFdDL8yBfMZxfOYx+KGGSsaF8JAwj/8sxgGqn9awOtZNuRx3XRQxBJC6J7ioyF2XPWl3oNGZCxTUa9dPOICEa+xF9UzEKbeMzAeusZzQLT2rDOrFZdlDo0Bj8TDumf5IluSQPZ0Xa6EaA5TPoKc4h0TmgtWKBeoeKyF6Nzt7eCA0D0gJdM+3bupBVNedGT+qs3gZXoH6WtiF+TqM7isCYsEuhUv4/mmXZxs9NGble1F9Ku850vrDU0s+HDVh5bVgjZ3Qe5FhY6BGRJygzZAmkRnO5fNNMwoa8jsq/pXGEsw5JURg91qAkl0ATHl3Y7c88TnubSr5674uvhHxAwoLeQY4IK3RY3tZ/sd/MyKfH2XCX2AIJmh1Zm1llOwcIC/dvrO7qFAb3UV9JdpL6IFR6KvszZ1a7rqn8IZhwog98oUV34N4CuiNQS2Lxt3TI56YrxeSJCef3Fgkwk8LIBzJqOdWsrPhPgz5xOhN92jqjgmubnpPM63VFDeS/6aHB65cpxvcgc3rSkrj2Tz+BQFv8xHrFsbTUdgICwYIr9N5zUgV3WB0WRQtZftnK0/1oNoLz4yjmzBeL5+b9UewS1j/qJfJ74iN9QeHShONC4MxJRp6r7zZMzA8+HgvY5nZgryO04GJTfPR7YVu+44Kk/WbcNmazk4RYLV1xaQwWE8iyFeULUW6QI9OKoFQtVEZSJw/EsQNPFLmtSH0lI4kRaTEcHlWgQUrHx/0dK9vp+JgFHU+3xGHc0iMvED9yXH/zRiU/LpSs/0jqwwxxXbqXc68rrfhigV9M77RhJaxoniGeQemSAohzpatPRzkclMbDSyXAspkTfYCI2m5hBGcytumkQyL88eDly+y+rhZpxWZOxQ2WW 3iOSAEzb FblJ7Q4aLZhStVm5a8GLQivOZxSFc6soVbRMgmJMFeKXFWnnXiZjiEpQji5qMCsNgtcWeDm88hfYYMhihL2DjLHUB78KIOXWT+EP+Yuvv0B8nfwT6zJud5B1++0hc+4mmbqpZcSG3TgL+zsE27OoHK4AyVJ2jIeGm9vnOp8A42r4KCIhZVjmwNfUCR5k2IDQWA1mTbd9Lq2vjDKnWeP0SZ/IjoNOfnD9M4dAufuVoQWYATnoHUgvWcti6MjGq1pYLwnSmP8Ers8TSXw7uRraL/FcqmjJuQ0jLWY8DjFTBuXvc7eIU2iw6/FSYfCwakLxIw4nQlBafeW0IbCa4AOu5kFE7U2h1p2AkKPFjma/s+meTeazSOrY0ZneQrDkbD/5O2TEFDPL4AfIiLNKsA6Fgcq7rLD8D0/iLn1Uh 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 22-08-24 17:18:29, Linus Torvalds wrote: > On Thu, 22 Aug 2024 at 17:11, Michal Hocko wrote: > > > > 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. > > I do like changing the naming to make it clear that it's not some kind > of general MM guarantee for any random allocation. > > So that's why I liked the NOFAIL_SMALL_ALLOC just to make people who > use it aware that no, they aren't getting a "get out of jail free" > card. Small means different things to different people. Also that small has a completely different meaning for the page allocator and for kvmalloc. I really do not like to carve any ambiguity like that into the flag that is supposed to be used for both. Quite honestly I am not even sure we have actual GFP_NOFAIL users of the page allocator outside of the MM (e.g. to implement SLUB internal allocations). git grep just takes too much time to process because the underlying allocator is not always immediately visible. Limiting NOFAIL semantic to SLUB and {kv}malloc allocators would make some sense then as it could enforce reasonable use more easily I guess. -- Michal Hocko SUSE Labs