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 C163CC433FE for ; Thu, 7 Oct 2021 16:37:55 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id A947061262 for ; Thu, 7 Oct 2021 16:37:55 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S242729AbhJGQjs (ORCPT ); Thu, 7 Oct 2021 12:39:48 -0400 Received: from smtp-out1.suse.de ([195.135.220.28]:33174 "EHLO smtp-out1.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233594AbhJGQjq (ORCPT ); Thu, 7 Oct 2021 12:39:46 -0400 Received: from relay2.suse.de (relay2.suse.de [149.44.160.134]) by smtp-out1.suse.de (Postfix) with ESMTP id E8E812240E; Thu, 7 Oct 2021 16:37:51 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1633624671; 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=pgKKsGQrUYNdgMl9z1+VDxyRxaQOGIIghSaW1BWRpLQ=; b=nSmKMl9h0mVz+YBvIPdVx/KLRm1kLqIBsQRUUH5vnJv224ZBJxU9QNZBit9ZeUDjGLBStN IWDiSX/UDYMESp75oloI0N61CqNg2dwN/GNRK58XvSwdf3KiIJn2vGdX8Acx+27CJArkwi 6qR7C5YRIuVUP9H0zEtT58WgRWmuo1A= Received: from suse.cz (unknown [10.100.201.86]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by relay2.suse.de (Postfix) with ESMTPS id 89075A3B88; Thu, 7 Oct 2021 16:37:50 +0000 (UTC) Date: Thu, 7 Oct 2021 18:37:49 +0200 From: Michal Hocko To: Suren Baghdasaryan 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, Chinwen Chang =?utf-8?B?KOW8temMpuaWhyk=?= , 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 Subject: Re: [PATCH v10 3/3] mm: add anonymous vma name refcounting Message-ID: References: <20211005184211.GA19804@duo.ucw.cz> <20211005200411.GB19804@duo.ucw.cz> <6b15c682-72eb-724d-bc43-36ae6b79b91a@redhat.com> 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-kernel@vger.kernel.org On Thu 07-10-21 08:45:21, Suren Baghdasaryan wrote: > On Thu, Oct 7, 2021 at 12:59 AM Michal Hocko wrote: > > > > On Wed 06-10-21 08:01:56, Suren Baghdasaryan wrote: > > > On Wed, Oct 6, 2021 at 2:27 AM David Hildenbrand wrote: > > > > > > > > On 06.10.21 10:27, Michal Hocko wrote: > > > > > On Tue 05-10-21 23:57:36, John Hubbard wrote: > > > > > [...] > > > > >> 1) Yes, just leave the strings in the kernel, that's simple and > > > > >> it works, and the alternatives don't really help your case nearly > > > > >> enough. > > > > > > > > > > I do not have a strong opinion. Strings are easier to use but they > > > > > are more involved and the necessity of kref approach just underlines > > > > > that. There are going to be new allocations and that always can lead > > > > > to surprising side effects. These are small (80B at maximum) so the > > > > > overall footpring shouldn't all that large by default but it can grow > > > > > quite large with a very high max_map_count. There are workloads which > > > > > really require the default to be set high (e.g. heavy mremap users). So > > > > > if anything all those should be __GFP_ACCOUNT and memcg accounted. > > > > > > > > > > I do agree that numbers are just much more simpler from accounting, > > > > > performance and implementation POV. > > > > > > > > +1 > > > > > > > > I can understand that having a string can be quite beneficial e.g., when > > > > dumping mmaps. If only user space knows the id <-> string mapping, that > > > > can be quite tricky. > > > > > > > > However, I also do wonder if there would be a way to standardize/reserve > > > > ids, such that a given id always corresponds to a specific user. If we > > > > use an uint64_t for an id, there would be plenty room to reserve ids ... > > > > > > > > I'd really prefer if we can avoid using strings and instead using ids. > > > > > > I wish it was that simple and for some names like [anon:.bss] or > > > [anon:dalvik-zygote space] reserving a unique id would work, however > > > some names like [anon:dalvik-/system/framework/boot-core-icu4j.art] > > > are generated dynamically at runtime and include package name. > > > Packages are constantly evolving, new ones are developed, names can > > > change, etc. So assigning a unique id for these names is not really > > > feasible. > > > > I still do not follow. If you need a globaly consistent naming then > > you need clear rules for that, no matter whether that is number or a > > file. How do you handle this with strings currently? > > Some names represent standard categories, some are unique. A simple > tool could calculate and report the total for each name, a more > advanced tool might recognize some standard names and process them > differently. From kernel's POV, it's just a name used by the userspace > to categorize anonymous memory areas. 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. -- Michal Hocko SUSE Labs