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=-7.3 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,USER_AGENT_SANE_1 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 4CE33C47096 for ; Thu, 3 Jun 2021 11:34:02 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id D410A613E9 for ; Thu, 3 Jun 2021 11:34:01 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org D410A613E9 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=chrisdown.name Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 5EDC36B0095; Thu, 3 Jun 2021 07:34:01 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 5C3D96B0096; Thu, 3 Jun 2021 07:34:01 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 48C0B6B0098; Thu, 3 Jun 2021 07:34:01 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 18ED16B0095 for ; Thu, 3 Jun 2021 07:34:01 -0400 (EDT) Received: from smtpin21.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id 9EE36D226 for ; Thu, 3 Jun 2021 11:34:00 +0000 (UTC) X-FDA: 78212203440.21.11D068A Received: from mail-wm1-f52.google.com (mail-wm1-f52.google.com [209.85.128.52]) by imf29.hostedemail.com (Postfix) with ESMTP id A0AED36D for ; Thu, 3 Jun 2021 11:33:42 +0000 (UTC) Received: by mail-wm1-f52.google.com with SMTP id r13so3194538wmq.1 for ; Thu, 03 Jun 2021 04:34:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chrisdown.name; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=dDlsfUVoPz4mflmjcY/17kiGQZC/D+4tAfNsl24/syY=; b=I33Sa5PdYGfNQKY6cAOIwcMXmeroW1m4Oz5alOZxht7s147JhQGghyjwGeESW8gRo6 SuP7K1TW+jJxffBQf2GxFw1F6/UzK1CV4s4VSF8AE9U4cL9xDRHxoG/oa6eHYczCRMj+ ahTYmh0FeW4SmS7S7hRi1WnWRh6Ci+cqtf3UA= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=dDlsfUVoPz4mflmjcY/17kiGQZC/D+4tAfNsl24/syY=; b=qXqTyvJ+8j1FXPgU0foMurD3t41nKlBV5Cknk3gRB/RbglpwTQsjjA8zek8wNElpkO AvpZF7G0mjM7rFT9LuDY6LUgaNmkUJlUxMCwDzM7hYqahpAtgEzn38UR06J5iSP1534Z PLDGTsGtKvXErRFOJVQAM5Uy/+xFfkObEI8Ht4FA57cKn+IyqE6rmgDhO1Sd4nGfRY6/ 54WL8BjeSbwaJi4RwNdTfkKPRdvf9tKMPPH7aTEy8+E5dHwtCDBozg5rD4PrfhuEzfSx OPFUAhMxtD7B8Jfp/cTdP/3TlgjNcXmoDaOEf3KkLLPznXLJHX4Iw+p4YppSKanIcm3F 85fQ== X-Gm-Message-State: AOAM530+h+JHSDDLZRC+Fnztfv8+hvE9+MHlK0LuCncr085GVR+UM0NF t51tfqZxEHi40alr/ZZNc8WtQQ== X-Google-Smtp-Source: ABdhPJzxGp42YLePRB+COjvEZscGLJ1f57oLKFzG258csqxuu/Y26xpaJN44MSJysb/GFA/LgvlFLA== X-Received: by 2002:a1c:7402:: with SMTP id p2mr9615488wmc.88.1622720039043; Thu, 03 Jun 2021 04:33:59 -0700 (PDT) Received: from localhost ([2620:10d:c093:400::5:6726]) by smtp.gmail.com with ESMTPSA id l16sm5710461wmj.47.2021.06.03.04.33.58 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 03 Jun 2021 04:33:58 -0700 (PDT) Date: Thu, 3 Jun 2021 12:33:58 +0100 From: Chris Down To: legion@kernel.org Cc: LKML , Linux Containers , Linux Containers , Linux FS Devel , linux-mm@kvack.org, Andrew Morton , Christian Brauner , "Eric W . Biederman" , Johannes Weiner , Michal Hocko Subject: Re: [PATCH v1] proc: Implement /proc/self/meminfo Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: User-Agent: Mutt/2.0.7 (481f3800) (2021-05-04) X-Rspamd-Queue-Id: A0AED36D Authentication-Results: imf29.hostedemail.com; dkim=pass header.d=chrisdown.name header.s=google header.b=I33Sa5Pd; dmarc=pass (policy=none) header.from=chrisdown.name; spf=pass (imf29.hostedemail.com: domain of chris@chrisdown.name designates 209.85.128.52 as permitted sender) smtp.mailfrom=chris@chrisdown.name X-Rspamd-Server: rspam03 X-Stat-Signature: ag1wfbhriogy3scui5khkj4gww5hjryq X-HE-Tag: 1622720022-294874 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: Hi Alexey, legion@kernel.org writes: >From: Alexey Gladkov >The /proc/meminfo contains information regardless of the cgroups >restrictions. This file is still widely used [1]. This means that all >these programs will not work correctly inside container [2][3][4]. Some >programs try to respect the cgroups limits, but not all of them >implement support for all cgroup versions [5]. > >Correct information can be obtained from cgroups, but this requires the >cgroups to be available inside container and the correct version of >cgroups to be supported. Then they should add support for it. We already export these metrics as part of cgroups and plenty of applications like Docker, podman, containerd, systemd, runc, etc already support it. Putting stuff in /proc to get around the problem of "some other metric I need might not be exported to a container" is not a very compelling argument. If they want it, then export it to the container... Ultimately, if they're going to have to add support for a new /proc/self/meminfo file anyway, these use cases should just do it properly through the already supported APIs. >+ for_each_online_node(nid) >+ mem_cgroup_nr_pages(memcg, nid, mi->pages); >+ >+ mi->slab_reclaimable = memcg_page_state(memcg, NR_SLAB_RECLAIMABLE_B); >+ mi->slab_unreclaimable = memcg_page_state(memcg, NR_SLAB_UNRECLAIMABLE_B); >+ mi->cached = memcg_page_state(memcg, NR_FILE_PAGES); >+ mi->swapcached = memcg_page_state(memcg, NR_SWAPCACHE); >+ mi->anon_pages = memcg_page_state(memcg, NR_ANON_MAPPED); >+ mi->mapped = memcg_page_state(memcg, NR_FILE_MAPPED); >+ mi->nr_pagetable = memcg_page_state(memcg, NR_PAGETABLE); >+ mi->dirty_pages = memcg_page_state(memcg, NR_FILE_DIRTY); >+ mi->writeback_pages = memcg_page_state(memcg, NR_WRITEBACK); >+} This presents an extraordinarily confusing API. A cgroup can contain more than one process, so it's not right to present this information as "meminfo" in /proc/self when these statistics may not have any relation to the current task under question.