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 X-Spam-Level: X-Spam-Status: No, score=-5.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 60024C43460 for ; Tue, 20 Apr 2021 14:05:10 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id B6CCC613B1 for ; Tue, 20 Apr 2021 14:05:09 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org B6CCC613B1 Authentication-Results: mail.kernel.org; dmarc=fail (p=quarantine dis=none) header.from=suse.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 1D18D6B006C; Tue, 20 Apr 2021 10:05:09 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 180726B006E; Tue, 20 Apr 2021 10:05:09 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 0708E6B0070; Tue, 20 Apr 2021 10:05:09 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0005.hostedemail.com [216.40.44.5]) by kanga.kvack.org (Postfix) with ESMTP id DDA476B006C for ; Tue, 20 Apr 2021 10:05:08 -0400 (EDT) Received: from smtpin40.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id 9C16F12EF for ; Tue, 20 Apr 2021 14:05:08 +0000 (UTC) X-FDA: 78052917096.40.796C39E Received: from mx2.suse.de (mx2.suse.de [195.135.220.15]) by imf06.hostedemail.com (Postfix) with ESMTP id A0FA0C0007FC for ; Tue, 20 Apr 2021 14:05:10 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1618927506; 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=N6JmTAHOdm3EBKzZL5WzHZUZAVTtx4LYm8/9OAbOF4I=; b=ew4B6zpLgm7CnWgrZy5ZalklxOHOI4v6mQdTC0jd8h5GfQImJbMaPOEGLsGl7ig/z9vbMu bESXKgEeT55ecoIIJ7whzdn0Q1nLOkLEWmvDf1fqwPTwAaFFS5KgerwM/fCj4bGcBUbez3 tmxzrHozEeNEGp+/qGyPBaZrJ/el3J8= Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id BAF81B061; Tue, 20 Apr 2021 14:05:06 +0000 (UTC) Date: Tue, 20 Apr 2021 16:05:05 +0200 From: Michal Hocko To: Matthew Wilcox Cc: Mike Rapoport , Jonathan Corbet , Alexey Dobriyan , Andrew Morton , Eric Dumazet , Mike Rapoport , linux-doc@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, netdev@vger.kernel.org Subject: Re: [PATCH v2] docs: proc.rst: meminfo: briefly describe gaps in memory accounting Message-ID: References: <20210420121354.1160437-1-rppt@kernel.org> <20210420132430.GB3596236@casper.infradead.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Server: rspam03 X-Rspamd-Queue-Id: A0FA0C0007FC X-Stat-Signature: 3n93kcxru8n7iwbs3tuw1bqp6ktiizih Received-SPF: none (suse.com>: No applicable sender policy available) receiver=imf06; identity=mailfrom; envelope-from=""; helo=mx2.suse.de; client-ip=195.135.220.15 X-HE-DKIM-Result: pass/pass X-HE-Tag: 1618927510-81143 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 Tue 20-04-21 15:57:08, Michal Hocko wrote: [...] > Usual memory consumption is usually something like LRU pages + Slab > memory + kernel stack + vmalloc used + pcp. > > > But I know that KernelStack is allocated through vmalloc these days, > > and I don't know whether VmallocUsed includes KernelStack or whether I > > can sum them. Similarly, is Mlocked a subset of Unevictable? Forgot to reply to these two. Yes they do. So if we want to be precise then you have to check the stack allocation configuration. There are just so many traps lurking here. Something you get used to over time but this is certainly far far away from an ideal state. What else we can expect from an ad hoc approach to providing data to userspace that was historically applied to this and many other proc interfaces. We are trying to be strict for some time but some mistakes are simply hard to fix up (e.g. accounting shmem as a page cache to name some more). -- Michal Hocko SUSE Labs