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 AAB38C433EF for ; Fri, 22 Apr 2022 10:58:45 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 2002C6B0074; Fri, 22 Apr 2022 06:58:45 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 1AF456B0075; Fri, 22 Apr 2022 06:58:45 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 076B36B0078; Fri, 22 Apr 2022 06:58:45 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (relay.hostedemail.com [64.99.140.27]) by kanga.kvack.org (Postfix) with ESMTP id E89606B0074 for ; Fri, 22 Apr 2022 06:58:44 -0400 (EDT) Received: from smtpin20.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay12.hostedemail.com (Postfix) with ESMTP id BE517121179 for ; Fri, 22 Apr 2022 10:58:44 +0000 (UTC) X-FDA: 79384216968.20.FD88381 Received: from mail-qt1-f173.google.com (mail-qt1-f173.google.com [209.85.160.173]) by imf02.hostedemail.com (Postfix) with ESMTP id BD44480024 for ; Fri, 22 Apr 2022 10:58:42 +0000 (UTC) Received: by mail-qt1-f173.google.com with SMTP id fu34so5207300qtb.8 for ; Fri, 22 Apr 2022 03:58:43 -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=QypjtVLosJi9K+p/leRPpb/U1nKpemLV34xYlxrVTho=; b=Yhd2wyuoROb2LgW9En5TdALxryVE8CW8M13ZqC/KTkBxqiEruz7oeltFzq5Yaqn6r4 8g+isYsvK0tKt9V+PoB/eg3GTYt2UTmD42NM7YU+6eW9g2j19eEEegShfpWl03nEy85Z iukDLpCwRwn1Dh/tcBqUVLFWEB44tLzipW2w/81L4YD4ZBEo9DGjMCizjaEzSyiWA8J9 gjmdqMtrHjuyOLx7c+OO1hX2hP/IojXwBrIQpBI9Ob1ulq+XUCf4udBoTzaBIG34gl4r hcd3IKtiOXdY/Rt7S8ynKR61wOcBDET5LJlaOUa8cXXoTN1CqIfwCtFcfOOCo7o9QNnw 2UEA== 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=QypjtVLosJi9K+p/leRPpb/U1nKpemLV34xYlxrVTho=; b=EXSb1qAihuP1BpB13uN3/CM5KQFkAkNh1ABLON3K8BCCwzjd6u7lFvUp3ZlMcdO/NV u0ZZej66BLg4/G8kIgSXPLXXCDi+itu6CC0Oo8TQqOuP2Ea+WBQ5mbcxTTiIKsJ9TQj0 bpJIrRcElTIGwkSoflMqYiIK3BevaXj+RDmsjkul5RFLEPqz0CQYRiYGZvNzAtxMMINS ECs77AK1/pj9TqgHJwYZb8fTHaSAutdrpqZcNk4X6GeiUw8zK3TvyN/miX2kffcL/xkw UcMIE7SHNkIzglhx9MvGtU0SMAgNweAzxAXH82gg1lpoqB2u0IEj/u55TUzR3JWETH5x 7Wwg== X-Gm-Message-State: AOAM530dFJ5iyP3bRZF8Pyp3cNWyyf9upKeWd8pkxyj/1SQy3LKDSj7K KhJr2u9GIUKRuqsXG9NpVQ== X-Google-Smtp-Source: ABdhPJyUw/DBNTUoA6r40E+V89EntU+6CVJ8v221kGQcJMu0tV7OZdPe5zSdIMrn6qY9Sjzvn+xQ/A== X-Received: by 2002:ac8:70da:0:b0:2f1:d195:cfaf with SMTP id g26-20020ac870da000000b002f1d195cfafmr2596174qtp.247.1650625123494; Fri, 22 Apr 2022 03:58:43 -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 c13-20020a37e10d000000b0069c268c37f1sm768427qkm.23.2022.04.22.03.58.42 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 22 Apr 2022 03:58:42 -0700 (PDT) Date: Fri, 22 Apr 2022 06:58:40 -0400 From: Kent Overstreet To: Michal Hocko Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org, linux-fsdevel@vger.kernel.org, roman.gushchin@linux.dev, hannes@cmpxchg.org Subject: Re: [PATCH 3/4] mm: Centralize & improve oom reporting in show_mem.c Message-ID: <20220422105840.wsrlxt3emw4vagcm@moria.home.lan> References: <20220419203202.2670193-4-kent.overstreet@gmail.com> <20220420165805.lg4k2iipnpyt4nuu@moria.home.lan> <20220421184213.tbglkeze22xrcmlq@moria.home.lan> <20220422083037.3pjdrusrn54fmfdf@moria.home.lan> <20220422094413.2i6dygfpul3toyqr@moria.home.lan> 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: BD44480024 X-Stat-Signature: j4s7gq496t68xzzsn5umaobt687e15hu Authentication-Results: imf02.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=Yhd2wyuo; spf=pass (imf02.hostedemail.com: domain of kent.overstreet@gmail.com designates 209.85.160.173 as permitted sender) smtp.mailfrom=kent.overstreet@gmail.com; dmarc=pass (policy=none) header.from=gmail.com X-HE-Tag: 1650625122-68239 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 12:51:09PM +0200, Michal Hocko wrote: > On Fri 22-04-22 05:44:13, Kent Overstreet wrote: > > On Fri, Apr 22, 2022 at 11:27:05AM +0200, Michal Hocko wrote: > > > We already do that in some form. We dump unreclaimable slabs if they > > > consume more memory than user pages on LRUs. We also dump all slab > > > caches with some objects. Why is this approach not good? Should we tweak > > > the condition to dump or should we limit the dump? These are reasonable > > > questions to ask. Your patch has dropped those without explaining any > > > of the motivation. > > > > > > I am perfectly OK to modify should_dump_unreclaim_slab to dump even if > > > the slab memory consumption is lower. Also dumping small caches with > > > handful of objects can be excessive. > > > > > > Wrt to shrinkers I really do not know what kind of shrinkers data would > > > be useful to dump and when. Therefore I am asking about examples. > > > > Look, I've given you the sample > > That sample is of no use as it doesn't really show how the additional > information is useful to analyze the allocation failure. I thought we > have agreed on that. You still haven't given any example where the > information is useful. So I do not really see any reason to change the > existing output. > > > output you asked for and explained repeatedly my > > rationale and you haven't directly responded; > > Your rationale is that we need more data and I do agree but it is not > clear which data and under which conditions. You're completely mischaractarizing and making this _way_ more complicated than it has to be, but I'll repeat: - For the slab changes, top 10 slabs in sorted order, with human readable units are _vastly_ easier on human eyes than pages of slab output, in the previous format - Shrinkers weren't reported on before at all, and as shrinkers are part of memory reclaim they're pretty integral to OOM debugging. > > if you have a reason you're > > against the patches please say so, but please give your reasoning. > > I have expressed that already, I believe, but let me repeat. I do not > like altering the oom report without a justification on how this new > output is useful. You have failed to explained that so far. Uh huh. Sounds like someone has some scripts he doesn't want to have to update.