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 E1D26C433B4 for ; Tue, 20 Apr 2021 14:05:11 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id ACB03613B8 for ; Tue, 20 Apr 2021 14:05:11 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231482AbhDTOFl (ORCPT ); Tue, 20 Apr 2021 10:05:41 -0400 Received: from mx2.suse.de ([195.135.220.15]:55310 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232359AbhDTOFj (ORCPT ); Tue, 20 Apr 2021 10:05:39 -0400 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: Precedence: bulk List-ID: X-Mailing-List: linux-fsdevel@vger.kernel.org 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