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 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 69530C433F5 for ; Thu, 7 Oct 2021 17:31:07 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 081DD60E09 for ; Thu, 7 Oct 2021 17:31:07 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 081DD60E09 Authentication-Results: mail.kernel.org; dmarc=fail (p=reject dis=none) header.from=google.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kvack.org Received: by kanga.kvack.org (Postfix) id 839C76B006C; Thu, 7 Oct 2021 13:31:06 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 7EA39900002; Thu, 7 Oct 2021 13:31:06 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 6B1AD6B0072; Thu, 7 Oct 2021 13:31:06 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0116.hostedemail.com [216.40.44.116]) by kanga.kvack.org (Postfix) with ESMTP id 596736B006C for ; Thu, 7 Oct 2021 13:31:06 -0400 (EDT) Received: from smtpin40.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id F34158249980 for ; Thu, 7 Oct 2021 17:31:05 +0000 (UTC) X-FDA: 78670332132.40.3FFAD21 Received: from mail-yb1-f177.google.com (mail-yb1-f177.google.com [209.85.219.177]) by imf04.hostedemail.com (Postfix) with ESMTP id 80BC35001985 for ; Thu, 7 Oct 2021 17:31:05 +0000 (UTC) Received: by mail-yb1-f177.google.com with SMTP id d131so15105905ybd.5 for ; Thu, 07 Oct 2021 10:31:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=SFMiH5k6bTZykMDXuEggSN9IEsmXGxbcwFTl7AqjDQA=; b=LXyUtPBgoQ0wuEV8jWO3qbh1aq19+NB+Lj3QNc8iavlMTVCNb3Lk/5pepq+lRv3WYF 94s526BQ8dmH0rW/nFdrbOb89wLb+OWnuC+dtYRmV+1sbJrOJhY9zSecE06C9uTm4xlH fdYjDMcpjNGy+xyqXbncZwjLyqXnUpnfnO7i3TsvElWM0IrdlUitVY2kmAUTtXWeO7jx lw+0RiP24lrJgk6TVwzr0YwO+kywWFJCBHnCq2t6zYMHIhiqydOujR+iLK080jPLYONs UVeo+0K7lnbrpeGaHWAnIRPbDndeAKwkb3Drmwgirj/J55VfQL74Zpd29efvaZAJy4Wn HtiA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=SFMiH5k6bTZykMDXuEggSN9IEsmXGxbcwFTl7AqjDQA=; b=zpQ7ZXLk975gMNsmevkEV8n61v8jegs6tpM3AaJRERDmUtdTfXme3wPO95iJeqFVnL JLPAE1AtCS4l5sfi4zYQl4lrFGp8cjsP1YO4uzTeacWtmkS29HuBE5TEQ4ts7EJVyApJ XXtvS929mfCTKNE44AJR/3pnhbSPAJ61usYzXuVT80WLojm79nFH5PAbUZ42Qte1iV0Q 3uaEIpbBiD8qA8/rMW0blr/Mp40etcDP/pgp/g/9HHMD2Z04MYpojVHWcHLm/6bCTXPY 5wPwyjG5YZCQONSwSmuoOpbRt/1jr6ThmnjoUZuX4rR7gK2a6HZC/TXxyEMfemMmolyc eUKQ== X-Gm-Message-State: AOAM532La3yjtJLZXUAMXLV6uOfzUBF7sJaazuNf/Ly3irSLm9fMAJd7 sstqnJGysMvQVBVzA/VydK90IlGTnn3iHzT7dfUB6w== X-Google-Smtp-Source: ABdhPJwpjKoLoBI5gOCik6Ve1waW1iJ2N/hIfjVfZ1uubfoQdCVIbn77Huwx2Za7fOFEIH/xXPzNZFvP9AfPUdJ//Pg= X-Received: by 2002:a25:552:: with SMTP id 79mr6071995ybf.202.1633627863712; Thu, 07 Oct 2021 10:31:03 -0700 (PDT) MIME-Version: 1.0 References: <20211005200411.GB19804@duo.ucw.cz> <6b15c682-72eb-724d-bc43-36ae6b79b91a@redhat.com> In-Reply-To: From: Suren Baghdasaryan Date: Thu, 7 Oct 2021 10:30:52 -0700 Message-ID: Subject: Re: [PATCH v10 3/3] mm: add anonymous vma name refcounting To: Michal Hocko Cc: David Hildenbrand , John Hubbard , Pavel Machek , Andrew Morton , Colin Cross , Sumit Semwal , Dave Hansen , Kees Cook , Matthew Wilcox , "Kirill A . Shutemov" , Vlastimil Babka , Johannes Weiner , Jonathan Corbet , Al Viro , Randy Dunlap , Kalesh Singh , Peter Xu , rppt@kernel.org, Peter Zijlstra , Catalin Marinas , vincenzo.frascino@arm.com, =?UTF-8?B?Q2hpbndlbiBDaGFuZyAo5by16Yym5paHKQ==?= , Axel Rasmussen , Andrea Arcangeli , Jann Horn , apopple@nvidia.com, Yu Zhao , Will Deacon , fenghua.yu@intel.com, thunder.leizhen@huawei.com, Hugh Dickins , feng.tang@intel.com, Jason Gunthorpe , Roman Gushchin , Thomas Gleixner , krisman@collabora.com, chris.hyser@oracle.com, Peter Collingbourne , "Eric W. Biederman" , Jens Axboe , legion@kernel.org, Rolf Eike Beer , Cyrill Gorcunov , Muchun Song , Viresh Kumar , Thomas Cedeno , sashal@kernel.org, cxfcosmos@gmail.com, Rasmus Villemoes , LKML , linux-fsdevel@vger.kernel.org, linux-doc@vger.kernel.org, linux-mm , kernel-team Content-Type: text/plain; charset="UTF-8" X-Rspamd-Server: rspam01 X-Rspamd-Queue-Id: 80BC35001985 X-Stat-Signature: qs1oqmknpbudzp34ucbea49c669nptkz Authentication-Results: imf04.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=LXyUtPBg; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf04.hostedemail.com: domain of surenb@google.com designates 209.85.219.177 as permitted sender) smtp.mailfrom=surenb@google.com X-HE-Tag: 1633627865-707593 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 Thu, Oct 7, 2021 at 10:25 AM 'Michal Hocko' via kernel-team wrote: > > On Thu 07-10-21 09:43:14, Suren Baghdasaryan wrote: > > On Thu, Oct 7, 2021 at 9:37 AM Michal Hocko 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. >