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 95B23C48BC4 for ; Thu, 15 Feb 2024 18:41:58 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 2ABE58D0010; Thu, 15 Feb 2024 13:41:58 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 234768D0006; Thu, 15 Feb 2024 13:41:58 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 087378D0010; Thu, 15 Feb 2024 13:41:58 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id EC3F68D0006 for ; Thu, 15 Feb 2024 13:41:57 -0500 (EST) Received: from smtpin10.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id C6BF58085D for ; Thu, 15 Feb 2024 18:41:57 +0000 (UTC) X-FDA: 81794907474.10.6ADD45B Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.223.131]) by imf03.hostedemail.com (Postfix) with ESMTP id 6B49920016 for ; Thu, 15 Feb 2024 18:41:55 +0000 (UTC) Authentication-Results: imf03.hostedemail.com; dkim=pass header.d=suse.com header.s=susede1 header.b=K4vEFx6D; dkim=pass header.d=suse.com header.s=susede1 header.b=K4vEFx6D; dmarc=pass (policy=quarantine) header.from=suse.com; spf=pass (imf03.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=1708022515; 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=6TTmhcKgvDK5cRi30z9TDoJsmkkknH993fB0Fcc6Lyc=; b=LgnDlMdiPuEMbUOQ9yugPNh8legNwbqva1yyFtbXsL0OcO7NdHl3rh8ft7Po0UMrf0M576 XBJIiKydRCoQlGoSttLBUnZtIASEMQCph/HmRouHdH3PbOAQf2eUH5NyqXROS8SRVWPWvw R0aN2mXXhcFOaocHeLrtPpUSK3TpJmA= ARC-Authentication-Results: i=1; imf03.hostedemail.com; dkim=pass header.d=suse.com header.s=susede1 header.b=K4vEFx6D; dkim=pass header.d=suse.com header.s=susede1 header.b=K4vEFx6D; dmarc=pass (policy=quarantine) header.from=suse.com; spf=pass (imf03.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=1708022515; a=rsa-sha256; cv=none; b=6OuB7nZzjJ3g6y1zQIQPQ/mOhAIp9dAwNwGiFy2J/Nz4OsIVhSrKCiSRlygJo0EsrATxhE aToKWew7THr3y6vU3CuGsP/2cA5DknGNVOgMq/JG+LKDoQXYiQzpy+6VwaxthY5rXBMKsG mGEhWAWcdee4tj4YHScnPUIDbqddilk= 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 86A671F8D4; Thu, 15 Feb 2024 18:41:53 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1708022513; 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=6TTmhcKgvDK5cRi30z9TDoJsmkkknH993fB0Fcc6Lyc=; b=K4vEFx6DegEwMgozfuuotjV3BWYlDtstShVBSQGmIfKcXE02tD/wKBMZ3ZDWFnIkAYJUQb jMNeeSOW35Iptt8fAW8rBJyMBz9K0Ol4aamcu+JboL85GBZsVXn5uSXdOlHpDyOOnNkU1b P++yHnoeeU7CCnNzEjV+bXV9ubUO8cs= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1708022513; 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=6TTmhcKgvDK5cRi30z9TDoJsmkkknH993fB0Fcc6Lyc=; b=K4vEFx6DegEwMgozfuuotjV3BWYlDtstShVBSQGmIfKcXE02tD/wKBMZ3ZDWFnIkAYJUQb jMNeeSOW35Iptt8fAW8rBJyMBz9K0Ol4aamcu+JboL85GBZsVXn5uSXdOlHpDyOOnNkU1b P++yHnoeeU7CCnNzEjV+bXV9ubUO8cs= 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 1DA2813A53; Thu, 15 Feb 2024 18:41:53 +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 CjnpBvFazmXdJAAAD6G6ig (envelope-from ); Thu, 15 Feb 2024 18:41:53 +0000 Date: Thu, 15 Feb 2024 19:41:52 +0100 From: Michal Hocko To: Kent Overstreet Cc: Suren Baghdasaryan , akpm@linux-foundation.org, vbabka@suse.cz, hannes@cmpxchg.org, roman.gushchin@linux.dev, mgorman@suse.de, dave@stgolabs.net, willy@infradead.org, liam.howlett@oracle.com, corbet@lwn.net, void@manifault.com, peterz@infradead.org, juri.lelli@redhat.com, catalin.marinas@arm.com, will@kernel.org, arnd@arndb.de, tglx@linutronix.de, mingo@redhat.com, dave.hansen@linux.intel.com, x86@kernel.org, peterx@redhat.com, david@redhat.com, axboe@kernel.dk, mcgrof@kernel.org, masahiroy@kernel.org, nathan@kernel.org, dennis@kernel.org, tj@kernel.org, muchun.song@linux.dev, rppt@kernel.org, paulmck@kernel.org, pasha.tatashin@soleen.com, yosryahmed@google.com, yuzhao@google.com, dhowells@redhat.com, hughd@google.com, andreyknvl@gmail.com, keescook@chromium.org, ndesaulniers@google.com, vvvvvv@google.com, gregkh@linuxfoundation.org, ebiggers@google.com, ytcoode@gmail.com, vincent.guittot@linaro.org, dietmar.eggemann@arm.com, rostedt@goodmis.org, bsegall@google.com, bristot@redhat.com, vschneid@redhat.com, cl@linux.com, penberg@kernel.org, iamjoonsoo.kim@lge.com, 42.hyeyoo@gmail.com, glider@google.com, elver@google.com, dvyukov@google.com, shakeelb@google.com, songmuchun@bytedance.com, jbaron@akamai.com, rientjes@google.com, minchan@google.com, kaleshsingh@google.com, kernel-team@android.com, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, iommu@lists.linux.dev, linux-arch@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-mm@kvack.org, linux-modules@vger.kernel.org, kasan-dev@googlegroups.com, cgroups@vger.kernel.org Subject: Re: [PATCH v3 31/35] lib: add memory allocations report in show_mem() Message-ID: References: <20240212213922.783301-1-surenb@google.com> <20240212213922.783301-32-surenb@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Rspamd-Queue-Id: 6B49920016 X-Rspam-User: X-Rspamd-Server: rspam04 X-Stat-Signature: fbh7j9pstoiz15psf5nrceiioec9qp9j X-HE-Tag: 1708022515-88050 X-HE-Meta: U2FsdGVkX1+4BrFHKlRMSSKxuhz8dYeNg6WEKE7+wWXKvFrLwtikKbAWFUNE8ZcOQW8XXd29rzVRlxY0hWpnIwyKAsGQ5+5jfrcvv+IbTN/nSRh6RynbTtTj+EvayBAO/Yw8db4CrM4SKAUiTuQFT57zTwZElN787b0H1t+lu4gbjtjfFklZVfHfSCUJC8acujTCR/Ie4s3Bvd6/Tdz0Ux4tGg8U4KRMhbi7/BhKB/UEz3SbdE1Aeem1q0mjHo6qo93FaQgsd53YTQdehZYwk78xACob5cBLiPNUcT9zHTx5Opeym/TKsFMpVxBKKWxNCj7v5h5aGrvjWgm/vkW4sQrsLNlQ7FjEt54U9lFUl+VLHkzi8fbOI152T4AxVq/MB1wGcQY6S1aTH52tXHHOCCzWPFjWyySSWm31b8TXrE807z2K1Mk52aHb28MuD70yOoyaGaz72/RRhwF72EP42JM11SdJHa8k55e02ZnQkNrEjAXxDdtSZxaz/NCyemCcQqvr4MjxW5AVwl25j0bQ/UA8koxwX/COn4eSvHeprO1YECoNYZFptUf+PEWE8dTl1EIEDel4ksE0ogqg38dN8D8w7B1TlwwV8HWc5XD8rb8IlggrbyEOgPTm4DNkDOsEUXmVWVieaNbMX8vLbUbymD6qjUdt/jMbNlNINNXX7XEBWVf8rAnfJ4llzfyjZcWHkGovgvKer6XzTpRW3719GpThAQTQt919yS9DHahf8L8t3qYeCewDL4L0ddMJc5pCBs0fvd7Vs95LSyEe77PH1DjpOcog3HLpx/X+9GXrJqvicoDD1j1XaxObNdk+PcHr9fd1gm7Mmk6GLVkDRuKmNJk54LB4JYWMBRh2sUo0+anz/ulZiBBjtE7nEf5Fy46TIf0lnejyHir9IKfNS4rVFffyjzhe4QdzL04N5LJkZfpyTnxkcTZynzVN+rfwcrcSftyZLyuWnIjaFG1K7Tj 1kR5olj0 zbsOyo9VVFl7a1AA4dKT+SoaxH7dAGbj1dULtK4NIvjeULn+1L6XzbrtYkWnGculJGUgcPuxNYgzlfzDoICfLobJ9TxtyAkCxfo9wkv+qG7AS++KWo95tnZ+u693+snDPahf6p3eylTtXi+Y9En3uaMMWJmtEV/kiM2U5rU95cT/+KpVx1Le0pVk3yuzEOhPm3xG5Pf7qz2tpmUp6sfJ9nXIBiELZBl2hxX7bLqGZs/vlHYMGM9v0gg6uq+0t6a1LhFs3bSB7Hr2WdSqASwwSBGFi1uxBuuvrwINz3MVIxoEfnT1zsoKznzd3Qi8k57X1KB+1qnWREeBgsbhAQWySdUCX6l3CI/uPm9Ag+HZf3dTIQOTtuQR4vYjW+y2Z+Os7InT1qJAoQRHiTqGwt5cVHeJlTCd+APDZ6O6ZuSOmXjZwprM= 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 15-02-24 13:29:40, Kent Overstreet wrote: > On Thu, Feb 15, 2024 at 08:47:59AM -0800, Suren Baghdasaryan wrote: > > On Thu, Feb 15, 2024 at 8:45 AM Michal Hocko wrote: > > > > > > On Thu 15-02-24 06:58:42, Suren Baghdasaryan wrote: > > > > On Thu, Feb 15, 2024 at 1:22 AM Michal Hocko wrote: > > > > > > > > > > On Mon 12-02-24 13:39:17, Suren Baghdasaryan wrote: > > > > > [...] > > > > > > @@ -423,4 +424,18 @@ 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 > > > > > > +#ifdef CONFIG_MEM_ALLOC_PROFILING > > > > > > + { > > > > > > + struct seq_buf s; > > > > > > + char *buf = kmalloc(4096, GFP_ATOMIC); > > > > > > + > > > > > > + if (buf) { > > > > > > + printk("Memory allocations:\n"); > > > > > > + seq_buf_init(&s, buf, 4096); > > > > > > + alloc_tags_show_mem_report(&s); > > > > > > + printk("%s", buf); > > > > > > + kfree(buf); > > > > > > + } > > > > > > + } > > > > > > +#endif > > > > > > > > > > I am pretty sure I have already objected to this. Memory allocations in > > > > > the oom path are simply no go unless there is absolutely no other way > > > > > around that. In this case the buffer could be preallocated. > > > > > > > > Good point. We will change this to a smaller buffer allocated on the > > > > stack and will print records one-by-one. Thanks! > > > > > > __show_mem could be called with a very deep call chains. A single > > > pre-allocated buffer should just do ok. > > > > Ack. Will do. > > No, we're not going to permanently burn 4k here. > > It's completely fine if the allocation fails, there's nothing "unsafe" > about doing a GFP_ATOMIC allocation here. Nobody is talking about safety. This is just a wrong thing to do when you are likely under OOM situation. This is a situation when you GFP_ATOMIC allocation is _likely_ to fail. Yes, yes you will get some additional memory reservers head room, but you shouldn't rely on that because that will make the output unreliable. Not something you want in situation when you really want to know that information. More over you do not need to preallocate a full page. -- Michal Hocko SUSE Labs