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 CBD78C4167B for ; Wed, 29 Nov 2023 08:59:33 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 335AD6B0365; Wed, 29 Nov 2023 03:59:33 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 2E63D6B0367; Wed, 29 Nov 2023 03:59:33 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 187946B0368; Wed, 29 Nov 2023 03:59:33 -0500 (EST) 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 067096B0365 for ; Wed, 29 Nov 2023 03:59:33 -0500 (EST) Received: from smtpin24.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id AD14D1C049B for ; Wed, 29 Nov 2023 08:59:32 +0000 (UTC) X-FDA: 81510393384.24.6681855 Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.223.131]) by imf12.hostedemail.com (Postfix) with ESMTP id 69BEB40011 for ; Wed, 29 Nov 2023 08:59:30 +0000 (UTC) Authentication-Results: imf12.hostedemail.com; dkim=pass header.d=suse.com header.s=susede1 header.b=LMaHEQHD; dmarc=pass (policy=quarantine) header.from=suse.com; spf=pass (imf12.hostedemail.com: domain of mhocko@suse.com designates 195.135.223.131 as permitted sender) smtp.mailfrom=mhocko@suse.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1701248370; 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=B1yHc5VrAmXwelDR9dNQ+LR2NWQ0Q1cDsi0EaonFx9k=; b=YOGDj5zTzEWHKDLlqDB8BDwfO2LF+grkcdezI5NWuiJJfEmOWdmH/6yhDXu3aaFzhkmTTe CiN5Sq7NDQPakm64UsjoFzT9Dpz+NFlS4/MHdH7PUURMqxpMsem55W7WD5jpvL4a7UIMNf 9FnhwP+RjPa0qIxosYz+LaEhhtBLUE4= ARC-Authentication-Results: i=1; imf12.hostedemail.com; dkim=pass header.d=suse.com header.s=susede1 header.b=LMaHEQHD; dmarc=pass (policy=quarantine) header.from=suse.com; spf=pass (imf12.hostedemail.com: domain of mhocko@suse.com designates 195.135.223.131 as permitted sender) smtp.mailfrom=mhocko@suse.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1701248370; a=rsa-sha256; cv=none; b=TdzXNbBhToFKCanHc1xVSwMbJ8OERxhpbj5TH2S9Bz0PHGYqwgdvSMWWigBZtV8+ewlHks rYyuSAYbuBgRqf7LSgwDJOb5D4d/I/wMEq9ll5PKtIGYq2PgQWAjbOYU/Fb+5skFIaNwAE 5oNM9OLRLXwn4IU4nywctU+FYGxy/Aw= 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 A7F541F88F; Wed, 29 Nov 2023 08:59:28 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1701248368; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=B1yHc5VrAmXwelDR9dNQ+LR2NWQ0Q1cDsi0EaonFx9k=; b=LMaHEQHDnalCvTB+9FmaMZs5JXGmYRIrO/sNXV8itLt3RsEkqJYg0HpLXsbI5WIivX1bIa x5F2oVg0V+wi1nQsT6slqzLv1UJ11tNgMu/JEsc/LH7Kgu1t4D1tATXIaVxp6Kw9Og/7IM 8lx99iHkea59ukfhnuhbzNT3PsLUmMM= 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 8A9EA13637; Wed, 29 Nov 2023 08:59:28 +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 aaraHnD9ZmV3bAAAD6G6ig (envelope-from ); Wed, 29 Nov 2023 08:59:28 +0000 Date: Wed, 29 Nov 2023 09:59:27 +0100 From: Michal Hocko To: Kent Overstreet Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org, Andrew Morton , Qi Zheng , Roman Gushchin Subject: Re: [PATCH 4/7] mm: Centralize & improve oom reporting in show_mem.c Message-ID: References: <20231122232515.177833-1-kent.overstreet@linux.dev> <20231122232515.177833-5-kent.overstreet@linux.dev> <20231128175439.6jarreie7cay74fn@moria.home.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20231128175439.6jarreie7cay74fn@moria.home.lan> X-Rspamd-Server: rspam09 X-Rspamd-Queue-Id: 69BEB40011 X-Stat-Signature: udwaespo1gehxebjgich6eb41814hudx X-Rspam-User: X-HE-Tag: 1701248370-518563 X-HE-Meta: U2FsdGVkX18Rq6OmBCGbjcXHvCK2tS3zlA8FVENH68Ovy5OE/V1Ye7pCkEdGZ92iJBOu/f/ScxwP9Id9U9bJK8Lo2+ZPeSltYyrCV0nhN5BSiLoGBZ2QNp22gJgI6tB9nN+P+8YfMfWNy+TWKCAEhFAmXAsyxbxaO0tRQK8FMyKzOYaeQintzrzNWZGtELu/nNjGu7cPbPiwwaS2ukITKJORy2Z+L3RHByiPIFQlTXl/xLFSJ2WMPpzmZyI9A/1P/MWY0c/XkZrTAIFvSoHrob1xR4Diush9mspFvPFgkSel+tcL67RlJrtghyq945u6SF+M8grQKTIlANg923rv+qStGo12Aq2pO9jh9UsMdmOy/ftxX66k1yHioyrSu5PAHOplg64OT+NhAQ3Eqo8bKfllSxFExutdvDj5kvgaoRco1QIUZ2VTWgb1fO7NESefvg/MK+Xb30c4MpYO2hvkeUUzd42sxGwcPIrb9uuZa3SPHyyylEW2px3MVfujqw6u5jPaDfM8TBnc8fdVBUc9m4K5xTo5Mu3UN+L6ruKyZ0BzGPsgHqKRY+OEqeEhJXa5CDYUSZsNkGuhL2WMqT3ZehKQY00Sz+6WjbTwoimAXvpIOFaaLNV4DT5KEZcZ2//b+zLKffdxuM+g6XZL9eqVdnyfivC+S9lTfne7/kxwtFlsYeSyrRvv4f6ZxBcDkC4IhMdB09wUFSotnlrIrVhR37Dyf8p1Wwws3uORkxzDsCJqvR6+flNyUo9Z5as1egWe/ugki7BqhxCXeLWoPmX8PLozqggS54siHJdFHh41uDza+Bwz2batusuiVKCGCTLMTNlKUPm/803mVtwrGCz1D+oudXPECNBedmNv2/Jsj7qFCEHz7pQVmoGMeZBO1R02rFYLuR8GdQHW+JcLGnkoKb17s2nCqz3K6sFZhj32ZyomDp8qcJlfR+Gwd7997IFqWJdlCh12YK1TzECR6kh I03MRpjp H92TzwJfK1yzTk213NY4Nz857LnlbqpKDc6mh+Jlu3EC7q0HU/CQMl9Etk4GDs/J3nfAcVFUELFM/QPIam8msfWebPHX9cE1uCgRsYr/u6dMH27Zc+arCW5ROABSw8ejE1wQElOma6yiwP2gVRc+gGpksR+xag2/OsF2hT3/OgbhBPiSjb8QzpOVdL+XGHzNjcdsJ2W5W02jaYT+hCfg08hrMgY5zRGQvMPAX2E0jVfGUJNkn1uoXNPrTrNS/AocLhMZr 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 Tue 28-11-23 12:54:39, Kent Overstreet wrote: > On Tue, Nov 28, 2023 at 11:07:18AM +0100, Michal Hocko wrote: [...] > > > @@ -423,4 +426,21 @@ void __show_mem(unsigned int filter, nodemask_t *nodemask, int max_zone_idx) > > > #ifdef CONFIG_MEMORY_FAILURE > > > printk("%lu pages hwpoisoned\n", atomic_long_read(&num_poisoned_pages)); > > > #endif > > > + > > > + buf = kmalloc(4096, GFP_ATOMIC); > > > > I really do not think we want to allow allocations from the OOM context. > > Is there any reason why this cannot be a statically allocated buffer? > > You've made this claim before without ever giving any reasoning behind > it. We are actively out of memory at the stage you would like to allocate memory. I am pretty sure I have mentioned this argument in the past. > It's GFP_ATOMIC; it has to work from _interrupt_ context, OOM context is > fine. This is a completely _different_ contexts. GFP_ATOMIC works around IRQ or any atomic context inability to wait for the reclaim by accessing the memory reserves. At the _global_ oom situation those reserves are extremely scarce resource. Debugging data is certainly not something we would want to compete with e.g. oom victims or their dependencies that might need to access those reserves in order to make a forward progress. Especially in case where the said debugging data is not detrimental to analyse the OOM situation. And to be completely honest, I haven't really seen any strong arguments for shrinker internal state dumping other than _in some very limited_ cases this _might_ be useful. > And no, we don't want to burn 4k on a static buffer that is almost never > used; people do care about making the kernel run on small systems. WE DO NOT ALLOCATE FROM OOM context, not to mention for something as disposable as debugging data which usefulness is not really clear. If there are systems which cannot effort a 4kb for static buffer then just disable this debugging data. -- Michal Hocko SUSE Labs