lkml.org 
[lkml]   [2021]   [Jun]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH v1] proc: Implement /proc/self/meminfo
Hi Alexey,

legion@kernel.org writes:
>From: Alexey Gladkov <legion@kernel.org>
>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.

\
 
 \ /
  Last update: 2021-06-03 13:36    [W:0.155 / U:0.924 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site