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 74314C54E5D for ; Tue, 12 Mar 2024 14:46:39 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 0DF238D0051; Tue, 12 Mar 2024 10:46:39 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 068B18D0017; Tue, 12 Mar 2024 10:46:39 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E4A758D0051; Tue, 12 Mar 2024 10:46:38 -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 CD9AA8D0017 for ; Tue, 12 Mar 2024 10:46:38 -0400 (EDT) Received: from smtpin01.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 5FB2E1C0BE3 for ; Tue, 12 Mar 2024 14:46:38 +0000 (UTC) X-FDA: 81888663276.01.0F23600 Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.223.131]) by imf09.hostedemail.com (Postfix) with ESMTP id F164F140013 for ; Tue, 12 Mar 2024 14:46:34 +0000 (UTC) Authentication-Results: imf09.hostedemail.com; dkim=pass header.d=suse.cz header.s=susede2_rsa header.b=LswGAEql; dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b="a6W/UZ0E"; dkim=pass header.d=suse.cz header.s=susede2_rsa header.b=LswGAEql; dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b="a6W/UZ0E"; spf=pass (imf09.hostedemail.com: domain of vbabka@suse.cz designates 195.135.223.131 as permitted sender) smtp.mailfrom=vbabka@suse.cz; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1710254795; 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=1IbOynCtiL2PaA5IeWxQtG1SaOtxW/QcAtTtLspaTMY=; b=A9Ltw5rWbnMTqkf1aklsCe6AWpZcgAikz4YjrofVmahFSC6op4PZ8hS0EbMyKYN+l+72RG OpGdlV7X+om/b4779GqYxjZaKaUE7bzHOR89IZnB8FwD/3gZY6RGlIBhMiWtRHb2lm3oSV ARi+c3qW68yuYDuWU5aCN3zt3WsYoRU= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1710254795; a=rsa-sha256; cv=none; b=riuXTbwZwNPXtbevHIDyW8964MfahX3WFT4Nv8xpWJ7AD3y384f4P2KkSWhHjNXAXut6O+ c3VcobKvP4tzhySS2suxi2SO8EPhwRI9iFgiO8A+CnA+XGzgkUgVeywd/oa6V7qA2WFfsc 4bJH2VIHCKRvckd9ZFc6XstW9Pu1I9M= ARC-Authentication-Results: i=1; imf09.hostedemail.com; dkim=pass header.d=suse.cz header.s=susede2_rsa header.b=LswGAEql; dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b="a6W/UZ0E"; dkim=pass header.d=suse.cz header.s=susede2_rsa header.b=LswGAEql; dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b="a6W/UZ0E"; spf=pass (imf09.hostedemail.com: domain of vbabka@suse.cz designates 195.135.223.131 as permitted sender) smtp.mailfrom=vbabka@suse.cz; dmarc=none Received: from imap1.dmz-prg2.suse.org (imap1.dmz-prg2.suse.org [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-out2.suse.de (Postfix) with ESMTPS id 3339F5D62C; Tue, 12 Mar 2024 14:46:33 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_rsa; t=1710254793; 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=1IbOynCtiL2PaA5IeWxQtG1SaOtxW/QcAtTtLspaTMY=; b=LswGAEqlwL3PRqPZ6pHPHQBlSmRIjjbylp0N+EMYSffkhlSiGUvX7piYuFisGLGKP6fhTV zJE79KVpaqFG5xOIwhp6o2hKytKM1bLDW02f0bXfdxOafL8WwqMwDi5r3RGXNB0lN1Il2h JzmKva3sAyVmKJdA/DjWyGjIRZpJzUo= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_ed25519; t=1710254793; 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=1IbOynCtiL2PaA5IeWxQtG1SaOtxW/QcAtTtLspaTMY=; b=a6W/UZ0EXMpxJ2eok5iYAeTFn6bf0ZUXhkmV09ZZXFyoY9x4+2UJJ3KinehsiGA669Yjku NcdXQhrfX4o1h3BQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_rsa; t=1710254793; 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=1IbOynCtiL2PaA5IeWxQtG1SaOtxW/QcAtTtLspaTMY=; b=LswGAEqlwL3PRqPZ6pHPHQBlSmRIjjbylp0N+EMYSffkhlSiGUvX7piYuFisGLGKP6fhTV zJE79KVpaqFG5xOIwhp6o2hKytKM1bLDW02f0bXfdxOafL8WwqMwDi5r3RGXNB0lN1Il2h JzmKva3sAyVmKJdA/DjWyGjIRZpJzUo= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_ed25519; t=1710254793; 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=1IbOynCtiL2PaA5IeWxQtG1SaOtxW/QcAtTtLspaTMY=; b=a6W/UZ0EXMpxJ2eok5iYAeTFn6bf0ZUXhkmV09ZZXFyoY9x4+2UJJ3KinehsiGA669Yjku NcdXQhrfX4o1h3BQ== 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 1A5D613795; Tue, 12 Mar 2024 14:46:33 +0000 (UTC) Received: from dovecot-director2.suse.de ([2a07:de40:b281:106:10:150:64:167]) by imap1.dmz-prg2.suse.org with ESMTPSA id hN8PBslq8GWDKAAAD6G6ig (envelope-from ); Tue, 12 Mar 2024 14:46:33 +0000 Message-ID: Date: Tue, 12 Mar 2024 15:46:32 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [Lsf-pc] [LSF/MM/BPF TOPIC] Reclamation interactions with RCU Content-Language: en-US To: NeilBrown , Kent Overstreet Cc: Dave Chinner , Matthew Wilcox , Amir Goldstein , paulmck@kernel.org, lsf-pc@lists.linux-foundation.org, linux-mm@kvack.org, linux-fsdevel , Jan Kara References: <170925937840.24797.2167230750547152404@noble.neil.brown.name> <170933687972.24797.18406852925615624495@noble.neil.brown.name> <170950594802.24797.17587526251920021411@noble.neil.brown.name> From: Vlastimil Babka In-Reply-To: <170950594802.24797.17587526251920021411@noble.neil.brown.name> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: F164F140013 X-Rspam-User: X-Rspamd-Server: rspam11 X-Stat-Signature: 6gd6ts8ypc59hn9joj4f7ck34ewdhh9u X-HE-Tag: 1710254794-591279 X-HE-Meta: U2FsdGVkX186UHPHvFc0D35pqW5oJVQTAl6E7Wi4YGAnCF/5PXNi3uqJ1RAaIgXsDLWM8TBX+zioUGNx+Yqq+ecxziOuUWIsflODHuJ2Ra+9hsHUxTH++giAEEr2xnxPNyBa79P3XDblqDTFYC2vcLvziaX8UY5SSWhC/MaaH0pZIaA0Pzn9iw8aK7rq0trCM4PkrpDz8VyA10GOpsRWdeRMDGc9O/OTeN9kuauRfMqnXF650cbMxkTquDLO3E3QM76R7SXCdHuI0kJ8d9rgTn+2VYGFhXnHKa6TO/rb9xtmSld1yXUpPQDeDb6YaXYVK+HxEyQxpFEUi/0g/tbGXq7/EIkdNZ63YfnGoQ9rPNnBVdh7RD7jQwq2caC5H9faYCEZp5I9IwM9ee401o+dkzOX9wBGYghcC3sqfuEMA0aF4lIInPQrgYARxOMR1qzixopa+fjh4Q08eAhWV6yynANjRdrCdQTDzFvP4VcZVK2jVKSosnSxM0cAHnG0NOQfZrSqoOPO9ISR6T2hCH9qMCn9OGzcWVyoowY/P5c6QrEEx2wRNLcAJKNarZcpv2wfWAUsFtp7msYSfc5m08jfi4E8HT+XYqYX1rc8f4eqHnKAjxYZZMMSuemol8MYiAXGmernueZ8VcCWVNEJPx4PTWNnKuXBSZ1YAVp12RYrJorABvXDusVJi7t3P7lBEx/yFvEchHiKzY4AyhmZDt6acQlhHv+Pd5VGNFo39hIalYB+wJa3G4S/Qx9OWdutNJnvlBXsOYz3jpxQeFslBAciMgFYemX6G176seIHnO1aIC0HcxWoP6nBqAOTy995GL91oR1s01lhUXWEQoSP9KV8cuwaKcsMRetivgPTDIq9nrmf7+l/ej5fAZL6yLNW/sPmeiYZd/87/tKHp2K5BSLCqT5fucePfz0Xs8faYjq7CdjlKnujI0acgDn1PuSpqNY0 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 3/3/24 23:45, NeilBrown wrote: > On Sat, 02 Mar 2024, Kent Overstreet wrote: >> >> *nod* >> >> > I suspect that most places where there is a non-error fallback already >> > use NORETRY or RETRY_MAYFAIL or similar. >> >> NORETRY and RETRY_MAYFAIL actually weren't on my radar, and I don't see >> _tons_ of uses for either of them - more for NORETRY. >> >> My go-to is NOWAIT in this scenario though; my common pattern is "try >> nonblocking with locks held, then drop locks and retry GFP_KERNEL". >> >> > But I agree that changing the meaning of GFP_KERNEL has a potential to >> > cause problems. I support promoting "GFP_NOFAIL" which should work at >> > least up to PAGE_ALLOC_COSTLY_ORDER (8 pages). >> >> I'd support this change. >> >> > I'm unsure how it should be have in PF_MEMALLOC_NOFS and >> > PF_MEMALLOC_NOIO context. I suspect Dave would tell me it should work in >> > these contexts, in which case I'm sure it should. >> > >> > Maybe we could then deprecate GFP_KERNEL. >> >> What do you have in mind? > > I have in mind a more explicit statement of how much waiting is > acceptable. > > GFP_NOFAIL - wait indefinitely > GFP_KILLABLE - wait indefinitely unless fatal signal is pending. > GFP_RETRY - may retry but deadlock, though unlikely, is possible. So > don't wait indefinitely. May abort more quickly if fatal > signal is pending. > GFP_NO_RETRY - only try things once. This may sleep, but will give up > fairly quickly. Either deadlock is a significant > possibility, or alternate strategy is fairly cheap. > GFP_ATOMIC - don't sleep - same as current. > > I don't see how "GFP_KERNEL" fits into that spectrum. The definition of > "this will try really hard, but might fail and we can't really tell you > what circumstances it might fail in" isn't fun to work with. The problem is if we set out to change everything from GFP_KERNEL to one of the above, it will take many years. So I think it would be better to just change the semantics of GFP_KERNEL too. If we change it to remove the "too-small to fail" rule, we might suddenly introduce crashes in unknown amount of places, so I don't think that's feasible. But if we change it to effectively mean GFP_NOFAIL (for non-costly allocations), there should be a manageable number of places to change to a variant that allows failure. Also if these places are GFP_KERNEL by mistake today, and should in fact allow failure, they would be already causing problems today, as the circumstances where too-small-to-fail is violated are quite rare (IIRC just being an oom victim, so somewhat close to GFP_KILLABLE). So changing GFP_KERNEL to GFP_NOFAIL should be the lowest risk (one could argue for GFP_KILLABLE but I'm afraid many places don't really handle that as they assume the too-small-to-fail without exceptions and are unaware of the oom victim loophole, and failing on any fatal signal increases the chances of this happening). > Thanks, > NeilBrown > > >> >> Deprecating GFP_NOFS and GFP_NOIO would be wonderful - those should >> really just be PF_MEMALLOC_NOFS and PF_MEMALLOC_NOIO, now that we're >> pushing for memalloc_flags_(save|restore) more. >> >> Getting rid of those would be a really nice cleanup beacuse then gfp >> flags would mostly just be: >> - the type of memory to allocate (highmem, zeroed, etc.) >> - how hard to try (don't block at all, block some, block forever) >> > >