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 5AAA8C433EF for ; Mon, 25 Apr 2022 09:28:30 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id D030E6B0074; Mon, 25 Apr 2022 05:28:29 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id CE41F6B007B; Mon, 25 Apr 2022 05:28:29 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id BC86B6B007D; Mon, 25 Apr 2022 05:28:29 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (relay.hostedemail.com [64.99.140.28]) by kanga.kvack.org (Postfix) with ESMTP id ACCAE6B0074 for ; Mon, 25 Apr 2022 05:28:29 -0400 (EDT) Received: from smtpin04.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 805592F85 for ; Mon, 25 Apr 2022 09:28:29 +0000 (UTC) X-FDA: 79394875938.04.A61ED1C Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.220.29]) by imf08.hostedemail.com (Postfix) with ESMTP id 20724160034 for ; Mon, 25 Apr 2022 09:28:23 +0000 (UTC) Received: from relay2.suse.de (relay2.suse.de [149.44.160.134]) by smtp-out2.suse.de (Postfix) with ESMTP id 7D8111F383; Mon, 25 Apr 2022 09:28:27 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1650878907; 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=XJL7zOUPuNZbvSE5//FwsrKzEzvOELetv4Ge89BtuA0=; b=VG4XYrO3nQfUEqfTNJeoropkEgsIJ4SE83/etN9dphG2T+NFvfF/WhEGJkcg1PdHefBV1B lcBTrQWDcl54rpTEXSoTGOR6UTwTygtZiyVdkWEApTAxe74pOwdn1nW1AiJH00L9v7WMG0 7ybbHu/wZj5vkTLsj9XjBNAOL5SXTWs= 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 E6FC12C141; Mon, 25 Apr 2022 09:28:26 +0000 (UTC) Date: Mon, 25 Apr 2022 11:28:26 +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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20220423004607.q4lbz2mplkhlbyhm@moria.home.lan> X-Rspamd-Queue-Id: 20724160034 X-Stat-Signature: 9yrsu1jutsem6cnh848qg9d5jo6hk5cu Authentication-Results: imf08.hostedemail.com; dkim=pass header.d=suse.com header.s=susede1 header.b=VG4XYrO3; dmarc=pass (policy=quarantine) header.from=suse.com; spf=pass (imf08.hostedemail.com: domain of mhocko@suse.com designates 195.135.220.29 as permitted sender) smtp.mailfrom=mhocko@suse.com X-Rspam-User: X-Rspamd-Server: rspam08 X-HE-Tag: 1650878903-33393 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 Fri 22-04-22 20:46:07, Kent Overstreet wrote: > On Fri, Apr 22, 2022 at 05:27:41PM -0700, Roman Gushchin wrote: [...] > > > In my experience, it's rare to be _so_ out of memory that small kmalloc > > > allocations are failing - we'll be triggering the show_mem() report before that > > > happens. > > > > I agree. However the OOM killer _has_ to make the progress even in such rare > > circumstances. Absolutely agreed! > Oh, and the concern is allocator recursion? Yeah, that's a good point. No, not really. The oom killer is running with PF_MEMALLOC context so no reclaim recursion is allowed. As I've already pointed out in other reply the context will have access to memory reserves without any constrains so it could deplete them completely resulting in other issues during the recovery. > 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. -- Michal Hocko SUSE Labs