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 25B21C433EF for ; Fri, 22 Apr 2022 23:48:25 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id A0E1A6B0073; Fri, 22 Apr 2022 19:48:24 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 9BC876B0074; Fri, 22 Apr 2022 19:48:24 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 883C56B0075; Fri, 22 Apr 2022 19:48:24 -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 790116B0073 for ; Fri, 22 Apr 2022 19:48:24 -0400 (EDT) Received: from smtpin08.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay13.hostedemail.com (Postfix) with ESMTP id 5060260A2C for ; Fri, 22 Apr 2022 23:48:24 +0000 (UTC) X-FDA: 79386156528.08.7C5A00C Received: from mail-qk1-f174.google.com (mail-qk1-f174.google.com [209.85.222.174]) by imf05.hostedemail.com (Postfix) with ESMTP id 5A27810002F for ; Fri, 22 Apr 2022 23:48:20 +0000 (UTC) Received: by mail-qk1-f174.google.com with SMTP id d198so6909773qkc.12 for ; Fri, 22 Apr 2022 16:48:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=9/2xDFh9dl7zEQ1Wno66tlhOklc1X6CUbTpyUD0JYSo=; b=GtSJCfb/kFq8IZZVn9cYuEpNofTiZEMRAjQfrkDfZ4MxVTKJPumEe82wv9zvlt1wdb YPGc+4HLi52g83DegnPV7Cj6RXbdrJo1Y8wo6s7UGnFDsKKta8q8Xx7jhgcCz4eU/a97 EuGLMkt0mIDNF29xe2qkJ7myJO7L0xrLSIgSa2r4Vc6xT0g/QfSYOVhK2iwYqw+/etOT /dd1n5RN3+QgA3B4tO1wy/se9l6wzI2XF9hwKP/ROBHn2/XvwNpvLSo0fRujXQimJSOG /oOMxhB+vD8N5gztL5XgScwovH24Y2a0EiUZ0e9mvHM+2ugwjmviB7CVAH6ON/Z9F+CU q0oA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=9/2xDFh9dl7zEQ1Wno66tlhOklc1X6CUbTpyUD0JYSo=; b=U5/sxecIpnhj0nM3V+PP3jzcS6bCyIN6xeuFuTvKMLAIRjjvHVHQ69HlQHB8aJRgQP aR8dataNwPAqsCITYgahpE93nffmoQSB5pW362Jup+iT1j5p3P/uM2d3v1t7ypjHXB7g zWyMFWTMcZk6ZaSZnV1isuxErU5J5T3LcKYynW1MUI+En4yknNvLopz5+hz+ix6hWyu+ qCs31f5BG7nID4hJyTyEZg5QNk+8vqQTyQ0mcNXh6MQYb44GhjkII9KnmjQr45dWIpYh 4pmqbZHwe4QQ7/OzgwSyuJ+XyKzQIdPNWKL50YNENnTrhcnXi7hrNYqGy0mqfHvpUKPl J4Rw== X-Gm-Message-State: AOAM531M0FvdeMic/q1usIqDktJDeyqBLDBoWjxgQaUMxJ2isEN41Ucb TeVWEnyC5tVCWlg43Mp9yQ== X-Google-Smtp-Source: ABdhPJyw5vkKW6b5EOOq344HLslU2RWAyR40NLeFfnTi3FFpV26KMen487nIt7tPNpC9/77RvhcVxg== X-Received: by 2002:a37:a247:0:b0:69d:5e7d:42b7 with SMTP id l68-20020a37a247000000b0069d5e7d42b7mr4281597qke.320.1650671303234; Fri, 22 Apr 2022 16:48:23 -0700 (PDT) Received: from moria.home.lan (c-73-219-103-14.hsd1.vt.comcast.net. [73.219.103.14]) by smtp.gmail.com with ESMTPSA id b2-20020a37b202000000b0069c7ad47221sm1543720qkf.38.2022.04.22.16.48.22 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 22 Apr 2022 16:48:22 -0700 (PDT) Date: Fri, 22 Apr 2022 19:48:20 -0400 From: Kent Overstreet To: Roman Gushchin 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: <20220422234820.plusgyixgybebfmi@moria.home.lan> References: <20220421234837.3629927-1-kent.overstreet@gmail.com> <20220421234837.3629927-14-kent.overstreet@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspam-User: X-Rspamd-Server: rspam11 X-Rspamd-Queue-Id: 5A27810002F X-Stat-Signature: a5epqat9hcyndom4d8dnyp6u4s5343s6 Authentication-Results: imf05.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b="GtSJCfb/"; spf=pass (imf05.hostedemail.com: domain of kent.overstreet@gmail.com designates 209.85.222.174 as permitted sender) smtp.mailfrom=kent.overstreet@gmail.com; dmarc=pass (policy=none) header.from=gmail.com X-HE-Tag: 1650671300-369189 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:09:48AM -0700, Roman Gushchin wrote: > To add a concern: largest shrinkers are usually memcg-aware. Scanning > over the whole cgroup tree (with potentially hundreds or thousands of cgroups) > and over all shrinkers from the oom context sounds like a bad idea to me. Why would we be scanning over the whole cgroup tree? We don't do that in the vmscan code, nor the new report. If the OOM is for a specific cgroup, we should probably only be reporting on memory usage for that cgroup (show_mem() is not currently cgroup aware, but perhaps it should be). > IMO it's more appropriate to do from userspace by oomd or a similar daemon, > well before the in-kernel OOM kicks in. The reason I've been introducing printbufs and the .to_text() method was specifically to make this code general enough to be available from sysfs/debugfs - so I see no reasons why a userspace oomd couldn't make use of it as well. > > Last but not least let me echo the concern from the other reply. Memory > > allocations are not really reasonable to be done from the oom context so > > the pr_buf doesn't sound like a good tool here. > > +1 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. However, if this turns out not to be the case in practice, or if there's a consensus now that we really want to guard against this, I have some thoughts. We could either: - mempool-ify printbufs as a whole - reserve some memory just for the show_mem() report, which would mean either adding support to printbuf for external buffers (subsuming what seq_buf does), or shrinker .to_text() methods would have to output to seq_buf instead of printbuf (ew, API fragmentation).