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 AB013C433EF for ; Sat, 23 Apr 2022 01:25:43 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id BBF256B0073; Fri, 22 Apr 2022 21:25:42 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id B47776B0075; Fri, 22 Apr 2022 21:25:42 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 9C1E16B0078; Fri, 22 Apr 2022 21:25:42 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (relay.hostedemail.com [64.99.140.26]) by kanga.kvack.org (Postfix) with ESMTP id 8A8BA6B0073 for ; Fri, 22 Apr 2022 21:25:42 -0400 (EDT) Received: from smtpin05.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 72A8E611AF for ; Sat, 23 Apr 2022 01:25:42 +0000 (UTC) X-FDA: 79386401724.05.4CFF6BF Received: from out0.migadu.com (out0.migadu.com [94.23.1.103]) by imf03.hostedemail.com (Postfix) with ESMTP id AF97C20019 for ; Sat, 23 Apr 2022 01:25:39 +0000 (UTC) Date: Fri, 22 Apr 2022 18:25:34 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1650677140; h=from:from:reply-to:subject:subject: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=12Aii0jWw/m/a/Ftf0Ul3RDKgJHLmfcJr6TYwlkHk18=; b=LgGXXyUCPiF5DAduAqYEHY34GgdGKvApqAY8LkDtSQR+EirE20cxkNSXZLjhg0cfEgTTqZ jHVO/j1Pj8LMS1RXoHtPVkftzxQg1QhJpCDs7Xq0NmxMkLS3qx0Fo373cMjI3Nqf7HJfNk yMUgGGzRsAee2PuBVAKxuI8Bbt458y0= X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Roman Gushchin To: Kent Overstreet Cc: Michal Hocko , 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-Migadu-Flow: FLOW_OUT X-Migadu-Auth-User: linux.dev X-Rspam-User: X-Rspamd-Server: rspam11 X-Rspamd-Queue-Id: AF97C20019 X-Stat-Signature: qhfr68b7h4n5x5i5x6z1co8zhoijpdd9 Authentication-Results: imf03.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=LgGXXyUC; spf=pass (imf03.hostedemail.com: domain of roman.gushchin@linux.dev designates 94.23.1.103 as permitted sender) smtp.mailfrom=roman.gushchin@linux.dev; dmarc=pass (policy=none) header.from=linux.dev X-HE-Tag: 1650677139-403716 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, Apr 22, 2022 at 08:46:07PM -0400, Kent Overstreet wrote: > On Fri, Apr 22, 2022 at 05:27:41PM -0700, Roman Gushchin wrote: > > You're scanning over a small portion of all shrinker lists (on a machine with > > cgroups), so the top-10 list has little value. > > Global ->count_objects() return the number of objects on the system/root_mem_cgroup > > level, not the shrinker's total. > > Not quite following what you're saying here...? > > If you're complaining that my current top-10-shrinker report isn't memcg aware, > that's valid - I can fix that. For memcg-aware shrinkers each memcg has it's own LRU (per node). If you want to print top-10 system-wide lists you need to call ->count_objects() for each shrinker for each memcg for each node. It's quite a lot of work for an oom context. > > > > 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. > > Oh, and the concern is allocator recursion? Yeah, that's a good point. Yes, but not the only problem. > > 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. And this is another problem: grabbing _any_ locks from the oom context is asking for trouble: you can potentially enter the oom path doing any allocation, so now you have to check that no allocations are ever made holding this lock. And I'm not aware of any reasonable way to test it, so most likely it ends up introducing some very subtle bags, which will be triggered once a year. Thanks!