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 9CEEAC47DD9 for ; Fri, 22 Mar 2024 01:47:55 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id E5FE36B007B; Thu, 21 Mar 2024 21:47:54 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id DE7EB6B0082; Thu, 21 Mar 2024 21:47:54 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C3B126B0083; Thu, 21 Mar 2024 21:47:54 -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 AF7626B007B for ; Thu, 21 Mar 2024 21:47:54 -0400 (EDT) Received: from smtpin28.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 2740EA1206 for ; Fri, 22 Mar 2024 01:47:54 +0000 (UTC) X-FDA: 81922988868.28.DB5FD07 Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.223.130]) by imf24.hostedemail.com (Postfix) with ESMTP id D2EE618000D for ; Fri, 22 Mar 2024 01:47:51 +0000 (UTC) Authentication-Results: imf24.hostedemail.com; dkim=pass header.d=suse.de header.s=susede2_rsa header.b=Df6szJWA; dkim=pass header.d=suse.de header.s=susede2_ed25519 header.b=0DKNwIPQ; dkim=pass header.d=suse.de header.s=susede2_rsa header.b=Df6szJWA; dkim=pass header.d=suse.de header.s=susede2_ed25519 header.b=0DKNwIPQ; spf=pass (imf24.hostedemail.com: domain of neilb@suse.de designates 195.135.223.130 as permitted sender) smtp.mailfrom=neilb@suse.de; dmarc=pass (policy=none) header.from=suse.de ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1711072072; a=rsa-sha256; cv=none; b=2UUfRtLk2Kbmh/0ty4CYaQyYp5euq008hzZvw5k8uBzcDWhFfBiHBuUzeACIbAE2aMjL9S 246HhI+Wv43l2qanH7n1LoCiOM1uWjE3UE9lio4tRu4/t0odyzFmKJDpjoJ37jklgQf+AD 7lv7W2xEQh936avJo2HLpnxNZMX1kyw= ARC-Authentication-Results: i=1; imf24.hostedemail.com; dkim=pass header.d=suse.de header.s=susede2_rsa header.b=Df6szJWA; dkim=pass header.d=suse.de header.s=susede2_ed25519 header.b=0DKNwIPQ; dkim=pass header.d=suse.de header.s=susede2_rsa header.b=Df6szJWA; dkim=pass header.d=suse.de header.s=susede2_ed25519 header.b=0DKNwIPQ; spf=pass (imf24.hostedemail.com: domain of neilb@suse.de designates 195.135.223.130 as permitted sender) smtp.mailfrom=neilb@suse.de; dmarc=pass (policy=none) header.from=suse.de ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1711072072; 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=qB5h1cXTtBf6CkxlPpVgndnqzX6pa6NxOnKxnnwpgIQ=; b=jEHlAiuiusT2pm4Xo8v0t9HEdbmDPRdqLwwX1RRH3fym4nipwhxp9XoRMrI18s2Q+ocIGq ZGAqDDfEgTKJeceZ2eznBc7qg18YmXhOHBcw4GAYzuD9cZSOjGv4CagneTXd/KPzA5AzD8 HtI2TkjM8+ezke67gDMxOJWfXrtt+7U= Received: from imap1.dmz-prg2.suse.org (imap1.dmz-prg2.suse.org [IPv6:2a07:de40:b281:104:10:150:64:97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by smtp-out1.suse.de (Postfix) with ESMTPS id 2C39D37DFF; Fri, 22 Mar 2024 01:47:50 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1711072070; h=from:from:reply-to: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; bh=qB5h1cXTtBf6CkxlPpVgndnqzX6pa6NxOnKxnnwpgIQ=; b=Df6szJWA4yMVMZXXaZKpkO+RDk4HiHOW6p6036TJcmuxfZxc+4N3HO605+iDXusIA0JeAq FajK1eVzkk0k68ZmQyM75+qUNegxJWX9n6LDaUuuNZ4jLgDx4NM9mtOAJyKXFkgXyTIsFZ HTi2uVe6yJIcTMUAVOkWFgCtrXWqCAM= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1711072070; h=from:from:reply-to: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; bh=qB5h1cXTtBf6CkxlPpVgndnqzX6pa6NxOnKxnnwpgIQ=; b=0DKNwIPQWBjFSjGgBFfQDYwn+HRVOUocDDR2vfX34H/fqKBbCivDSBb9P5K6CH3kYgrPBA 4Pqr/djfAixVdKBA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1711072070; h=from:from:reply-to: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; bh=qB5h1cXTtBf6CkxlPpVgndnqzX6pa6NxOnKxnnwpgIQ=; b=Df6szJWA4yMVMZXXaZKpkO+RDk4HiHOW6p6036TJcmuxfZxc+4N3HO605+iDXusIA0JeAq FajK1eVzkk0k68ZmQyM75+qUNegxJWX9n6LDaUuuNZ4jLgDx4NM9mtOAJyKXFkgXyTIsFZ HTi2uVe6yJIcTMUAVOkWFgCtrXWqCAM= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1711072070; h=from:from:reply-to: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; bh=qB5h1cXTtBf6CkxlPpVgndnqzX6pa6NxOnKxnnwpgIQ=; b=0DKNwIPQWBjFSjGgBFfQDYwn+HRVOUocDDR2vfX34H/fqKBbCivDSBb9P5K6CH3kYgrPBA 4Pqr/djfAixVdKBA== Received: from imap1.dmz-prg2.suse.org (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by imap1.dmz-prg2.suse.org (Postfix) with ESMTPS id 15349137D4; Fri, 22 Mar 2024 01:47:45 +0000 (UTC) Received: from dovecot-director2.suse.de ([10.150.64.162]) by imap1.dmz-prg2.suse.org with ESMTPSA id /D6+KkHj/GUHPQAAD6G6ig (envelope-from ); Fri, 22 Mar 2024 01:47:45 +0000 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit MIME-Version: 1.0 From: "NeilBrown" To: "Dan Carpenter" Cc: "Kent Overstreet" , "Dave Chinner" , "Matthew Wilcox" , "Amir Goldstein" , paulmck@kernel.org, lsf-pc@lists.linux-foundation.org, linux-mm@kvack.org, "linux-fsdevel" , "Jan Kara" Subject: Re: [Lsf-pc] [LSF/MM/BPF TOPIC] Reclamation interactions with RCU In-reply-to: <22363d0a-71db-4ba7-b5e1-8bb515811d1c@moroto.mountain> References: , , , <170925937840.24797.2167230750547152404@noble.neil.brown.name>, , , <170933687972.24797.18406852925615624495@noble.neil.brown.name>, , <170950594802.24797.17587526251920021411@noble.neil.brown.name>, <22363d0a-71db-4ba7-b5e1-8bb515811d1c@moroto.mountain> Date: Fri, 22 Mar 2024 12:47:42 +1100 Message-id: <171107206231.13576.16550758513765438714@noble.neil.brown.name> X-Rspamd-Server: rspam08 X-Rspamd-Queue-Id: D2EE618000D X-Stat-Signature: 77j163pgd3cicpq9z5eqzfxxej4ec3d5 X-Rspam-User: X-HE-Tag: 1711072071-520585 X-HE-Meta: U2FsdGVkX1828xvy8h5Sl/EsctQ33CGMjvNh9XlEaKWaMh/om9nIjJjzC5G+xVXdGDhKtF7F22Z4rtMgOL/2vG+eUEbEcolUeu6U7/c5zdXOtg+woAk81T1cmiSx8Hwspvj2v+SDG5fz++8AVYvnAjbhcz/UDn8CgtVB1WKr91lh3ncAxtQ3MYVMgMM6OH4RDm5/EmpWqoxQTgjhyDP0vbpomB3zhzYJj0I0ucDeTnw6qRd8Vqq8xSVc4jNxwAVol1t5jZyB068D65wwwVxCbvPRSvn22O84tJmtf8yP8lJcyTgvf4Ifq7LZxhQL4wnxIyvIxNn13zw942KMPFGrj/EMau3ttAo0i13Yp1ndUfco/VUn9xNU+q7qOx5SPhp+YvZfCi7D5CxK8jDqtQZZb+P14dquzkuzLUeFxHf8YGXfXWs/ewZ2ntVngnnfrninkvUpsQM0SMea9iNOdDYoPkIOeNYw7PKqcl/y/1Hq8twGf/kJftR1FNqal8YHr9H3oBbZpuR9bNpgZSPDe9r4akWWSbUOSyhCnRQyiXlTQQHmXHJs1oiPoR0bemeMyPvaD8/6+hgyCoqs8MEgOnI+5UMukBtGw9KW9PDfAYbznzgtjgW77slTLOAWsaj5nzS/KGqJK9tyKTnPFMbZDshmIpXmsKSjlx3s1BU5hagUe/U92ztyToNLAvT++znFVoBIz3SyLYYEBVeBeOyBgZJrrQ4klPx/ILI1wC1Pc2mcbwTDVnzNKC/91XrYBkG6uzXK4YMZZOzA2S92RjxhROgKYiheOcgAAqcrdbUo7wnkhiqY2GtEZoy1XXfEy32mJBidHQp9T2jzD18+xBypVbu+j6LQKH9FliCZMMaoNuVvvbqsucQ4saERZpkQPF6w341wtzerYaV37NRbvnCFpY1jXARZU/bh0ZksmHddHsIpJIktrkpXa4bdqavh//nMiciBHd/L89pq4HJ9FwTRdfi 5rFM8e9l Vausg+H+OOOraXjSCRmpF7Cj9+upK9d5PJ06+9mKHHa+A+TNNhPYKIMSiIc4x/o+V5BNkHj+pUjbRa28i/G/liDpngX4Akc+A+FiHQw7lC5dv1wk6a9DD9bf5U6GT9hf4C6YMhJyvLuuMuFuIq5zaxsip9niUequwaBnQ/5RfNJttILT5TASTFD+T6IQ9y/x6L7AUWhns1BVQ9gvXnb1Qmu8lXqAFUaXw2VL49B/BF/EGG6s= 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, 21 Mar 2024, Dan Carpenter wrote: > On Mon, Mar 04, 2024 at 09:45:48AM +1100, NeilBrown wrote: > > I have in mind a more explicit statement of how much waiting is > > acceptable. > > > > GFP_NOFAIL - wait indefinitely > > Why not call it GFP_SMALL? It wouldn't fail. The size would have to be > less than some limit. If the size was too large, that would trigger a > WARN_ON_ONCE(). I would be happy with GFP_SMALL. It would never return NULL but might block indefinitely. It would (as you say) WARN (maybe ONCE) if the size was considered "COSTLY" and would possibly BUG if the size exceeded KMALLOC_MAX_SIZE. > > I obviously understand that this duplicates the information in the size > parameter but the point is that GFP_SMALL allocations have been > reviewed, updated, and don't have error handling code. We are on the same page here. > > We'd keep GFP_KERNEL which would keep the existing behavior. (Which is > that it can sleep and it can fail). I think that maps to GFP_RETRY but > GFP_RETRY is an uglier name. Can it fail though? I know it is allowed to, but does it happen? I think I would prefer the normal approach for allocations that are (or might be) too large for GFP_SMALL was to *not* risk triggering oom. So I'd rather we didn't have GFP_KERNEL (which I think does have that risk) and instead (maybe) GFP_LARGE which sleeps but will return NULL when an OOM condition is looming. So we only get OOM for GFP_SMALL allocations (because not failing simplifies the code), and where it is explicitly requested - like for user-space allocations and probably for file cache allocations. But I think that keeping it simple and only adding GFP_SMALL as we have discussed would be a big step in the right direction and we don't need to complicate it with other ideas. Thanks, NeilBrown > > People could still use __GFP_NOFAIL for larger allocations. > > regards, > dan carpenter > > >