Re: [PATCH v10 3/3] mm: add anonymous vma name refcounting

From: Suren Baghdasaryan <surenb@google.com>
To: Michal Hocko <mhocko@suse.com>
Cc: "David Hildenbrand" <david@redhat.com>,
	"John Hubbard" <jhubbard@nvidia.com>,
	"Pavel Machek" <pavel@ucw.cz>,
	"Andrew Morton" <akpm@linux-foundation.org>,
	"Colin Cross" <ccross@google.com>,
	"Sumit Semwal" <sumit.semwal@linaro.org>,
	"Dave Hansen" <dave.hansen@intel.com>,
	"Kees Cook" <keescook@chromium.org>,
	"Matthew Wilcox" <willy@infradead.org>,
	"Kirill A . Shutemov" <kirill.shutemov@linux.intel.com>,
	"Vlastimil Babka" <vbabka@suse.cz>,
	"Johannes Weiner" <hannes@cmpxchg.org>,
	"Jonathan Corbet" <corbet@lwn.net>,
	"Al Viro" <viro@zeniv.linux.org.uk>,
	"Randy Dunlap" <rdunlap@infradead.org>,
	"Kalesh Singh" <kaleshsingh@google.com>,
	"Peter Xu" <peterx@redhat.com>,
	rppt@kernel.org, "Peter Zijlstra" <peterz@infradead.org>,
	"Catalin Marinas" <catalin.marinas@arm.com>,
	vincenzo.frascino@arm.com,
	"Chinwen Chang (張錦文)" <chinwen.chang@mediatek.com>,
	"Axel Rasmussen" <axelrasmussen@google.com>,
	"Andrea Arcangeli" <aarcange@redhat.com>,
	"Jann Horn" <jannh@google.com>,
	apopple@nvidia.com, "Yu Zhao" <yuzhao@google.com>,
	"Will Deacon" <will@kernel.org>,
	fenghua.yu@intel.com, thunder.leizhen@huawei.com,
	"Hugh Dickins" <hughd@google.com>,
	feng.tang@intel.com, "Jason Gunthorpe" <jgg@ziepe.ca>,
	"Roman Gushchin" <guro@fb.com>,
	"Thomas Gleixner" <tglx@linutronix.de>,
	krisman@collabora.com, chris.hyser@oracle.com,
	"Peter Collingbourne" <pcc@google.com>,
	"Eric W. Biederman" <ebiederm@xmission.com>,
	"Jens Axboe" <axboe@kernel.dk>,
	legion@kernel.org, "Rolf Eike Beer" <eb@emlix.com>,
	"Cyrill Gorcunov" <gorcunov@gmail.com>,
	"Muchun Song" <songmuchun@bytedance.com>,
	"Viresh Kumar" <viresh.kumar@linaro.org>,
	"Thomas Cedeno" <thomascedeno@google.com>,
	sashal@kernel.org, cxfcosmos@gmail.com,
	"Rasmus Villemoes" <linux@rasmusvillemoes.dk>,
	LKML <linux-kernel@vger.kernel.org>,
	linux-fsdevel@vger.kernel.org, linux-doc@vger.kernel.org,
	linux-mm <linux-mm@kvack.org>,
	kernel-team <kernel-team@android.com>
Subject: Re: [PATCH v10 3/3] mm: add anonymous vma name refcounting
Date: Thu, 7 Oct 2021 10:30:52 -0700	[thread overview]
Message-ID: <CAJuCfpHM-W3iAANgudmgivz+aFMWxdVpPnZgQvibxwVE=L098g@mail.gmail.com> (raw)
In-Reply-To: <YV8tlUTdsiVuACx+@dhcp22.suse.cz>

On Thu, Oct 7, 2021 at 10:25 AM 'Michal Hocko' via kernel-team
<kernel-team@android.com> wrote:
>
> On Thu 07-10-21 09:43:14, Suren Baghdasaryan wrote:
> > On Thu, Oct 7, 2021 at 9:37 AM Michal Hocko <mhocko@suse.com> wrote:
> [...]
> > > OK, so there is no real authority or any real naming convention. You
> > > just hope that applications will behave so that the consumer of those
> > > names can make proper calls. Correct?
> > >
> > > In that case the same applies to numbers and I do not see any strong
> > > argument for strings other than it is more pleasing to a human eye when
> > > reading the file. And that doesn't sound like a strong argument to make
> > > the kernel more complicated. Functionally both approaches are equal from
> > > a practical POV.
> >
> > I don't think that's correct. Names like [anon:.bss],
> > [anon:dalvik-zygote space] and
> > [anon:dalvik-/system/framework/boot-core-icu4j.art] provide user with
> > actionable information about the use of that memory or the allocator
> > using it.
>
> No, none of the above is really actionable without a common
> understanding. Both dalvik* are a complete gibberish to me.

Ok, maybe I was unclear. Some names, as the first two in the above
example are quite standard for Android and tools do use them to
identify specific specialized areas. Some names are not standardized
and can contain package names, like
anon:dalvik-/system/framework/boot-core-icu4j.art. In this case while
tools do not process them in any special way, they still convey enough
information for a user to identify the corresponding component.

> --
> Michal Hocko
> SUSE Labs
>
> --
> To unsubscribe from this group and stop receiving emails from it, send an email to kernel-team+unsubscribe@android.com.
>