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 BE516C433F5 for ; Tue, 26 Apr 2022 07:17:43 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 4355D6B0074; Tue, 26 Apr 2022 03:17:43 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 3E4546B0075; Tue, 26 Apr 2022 03:17:43 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 2ABCA6B0078; Tue, 26 Apr 2022 03:17:43 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (relay.hostedemail.com [64.99.140.25]) by kanga.kvack.org (Postfix) with ESMTP id 190836B0074 for ; Tue, 26 Apr 2022 03:17:43 -0400 (EDT) Received: from smtpin30.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id E528625658 for ; Tue, 26 Apr 2022 07:17:42 +0000 (UTC) X-FDA: 79398175164.30.C1A7A9D Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.220.28]) by imf17.hostedemail.com (Postfix) with ESMTP id AEC8B40049 for ; Tue, 26 Apr 2022 07:17:35 +0000 (UTC) Received: from relay2.suse.de (relay2.suse.de [149.44.160.134]) by smtp-out1.suse.de (Postfix) with ESMTP id C2E6E210EA; Tue, 26 Apr 2022 07:17:40 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1650957460; 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=E341m0oGAZ8uwfYf1PyOsWw2EY2ezQuuipQASY4qGhM=; b=HDAJXwas5NvCqoiwQ7rHZHQ0CIxgB0k64TTcJDFBbBPmbmlYEtZEgoyDMKzktRiMq8g43s jbaUFHMY7zDJ0b7SsFz/ywwwxzjoQKkex/6FYfVDeotPaaGalAH5DhVqFUbjp+N9ReAUB2 EIfEH/eIZDzw3BtusTQi5w69L1izR3Y= Received: from suse.cz (unknown [10.100.201.86]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by relay2.suse.de (Postfix) with ESMTPS id 4270D2C141; Tue, 26 Apr 2022 07:17:40 +0000 (UTC) Date: Tue, 26 Apr 2022 09:17:39 +0200 From: Michal Hocko To: Kent Overstreet Cc: Roman Gushchin , linux-kernel@vger.kernel.org, linux-mm@kvack.org, linux-fsdevel@vger.kernel.org, hch@lst.de, hannes@cmpxchg.org, akpm@linux-foundation.org, linux-clk@vger.kernel.org, linux-tegra@vger.kernel.org, linux-input@vger.kernel.org, rostedt@goodmis.org Subject: Re: [PATCH v2 8/8] mm: Centralize & improve oom reporting in show_mem.c Message-ID: References: <20220421234837.3629927-1-kent.overstreet@gmail.com> <20220421234837.3629927-14-kent.overstreet@gmail.com> <20220422234820.plusgyixgybebfmi@moria.home.lan> <20220423004607.q4lbz2mplkhlbyhm@moria.home.lan> <20220425152811.pg2dse4zybpnpaa4@moria.home.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20220425152811.pg2dse4zybpnpaa4@moria.home.lan> X-Rspamd-Queue-Id: AEC8B40049 X-Stat-Signature: fckzich69z4o9fgxquudbiedax1danax Authentication-Results: imf17.hostedemail.com; dkim=pass header.d=suse.com header.s=susede1 header.b=HDAJXwas; dmarc=pass (policy=quarantine) header.from=suse.com; spf=pass (imf17.hostedemail.com: domain of mhocko@suse.com designates 195.135.220.28 as permitted sender) smtp.mailfrom=mhocko@suse.com X-Rspam-User: X-Rspamd-Server: rspam08 X-HE-Tag: 1650957455-782898 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: On Mon 25-04-22 11:28:11, Kent Overstreet wrote: > On Mon, Apr 25, 2022 at 11:28:26AM +0200, Michal Hocko wrote: > > > > > Do you know if using memalloc_noreclaim_(save|restore) is sufficient for that, > > > or do we want GFP_ATOMIC? I'm already using GFP_ATOMIC for allocations when we > > > generate the report on slabs, since we're taking the slab mutex there. > > > > No it's not. You simply _cannot_ allocate from the oom context. > > Hmm, no, that can't be right. I've been using the patch set and it definitely > works, at least in my testing. Yes, the world will not fall down and it really depends on the workload what kind of effect this might have. > Do you mean to say that we shouldn't? Can you explain why? I have already touched on that but let me reiterate. Allocation context called from the oom path will have an unbound access to memory reserves. Those are a last resort emergency pools of memory that are not available normally and there are areas which really depend on them to make a further progress to release the memory pressure. Swap over NFS would be one such example. If some other code path messes with those reserves the swap IO path could fail with all sorts of fallouts. So to be really exact in my statement. You can allocate from the OOM context but it is _strongly_ discouraged unless there is no other way around that. I would even claim that the memory reclaim in general shouldn't rely on memory allocations (other than mempools). If an allocation is really necessary then an extra care has to prevent from complete memory depletion. -- Michal Hocko SUSE Labs