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 6C998C4332F for ; Thu, 7 Oct 2021 02:29:33 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id D56D061248 for ; Thu, 7 Oct 2021 02:29:32 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org D56D061248 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=linux-foundation.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kvack.org Received: by kanga.kvack.org (Postfix) id 3915E6B006C; Wed, 6 Oct 2021 22:29:32 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 340E96B0071; Wed, 6 Oct 2021 22:29:32 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 1E1B56B0073; Wed, 6 Oct 2021 22:29:32 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0008.hostedemail.com [216.40.44.8]) by kanga.kvack.org (Postfix) with ESMTP id 09CF66B006C for ; Wed, 6 Oct 2021 22:29:32 -0400 (EDT) Received: from smtpin08.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id A347130C9A for ; Thu, 7 Oct 2021 02:29:31 +0000 (UTC) X-FDA: 78668060142.08.D00A2FA Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by imf27.hostedemail.com (Postfix) with ESMTP id 34C0670148DD for ; Thu, 7 Oct 2021 02:29:31 +0000 (UTC) Received: by mail.kernel.org (Postfix) with ESMTPSA id 53E5561215; Thu, 7 Oct 2021 02:29:28 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linux-foundation.org; s=korg; t=1633573770; bh=QKnJdE88voYB/9FaSah2G1VK75svKZo3+imFlVbkWFk=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=sy3Id8Xw5K5JSS0QPe6KDaxwGmEsoiHtqVrOeqe1WMmSTAOI9kUw4iT3U1l7U1Buu 3w5tGvkoDfNxV23My6X1HDBhvus6DnOB/Q8phFYwuZC071WMp5Bs8FZl11x3GMauiE Im+2fhvnN7zYh48vimu0ZpWrbH7fQ4uo59x+NuAc= Date: Wed, 6 Oct 2021 19:29:27 -0700 From: Andrew Morton To: Suren Baghdasaryan Cc: David Hildenbrand , Michal Hocko , John Hubbard , Pavel Machek , 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?Q?=E5=BC=B5=E9=8C=A6=E6=96=87?=) , 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: <20211006192927.f7a735f1afe4182bf4693838@linux-foundation.org> In-Reply-To: References: <20211001205657.815551-1-surenb@google.com> <20211001205657.815551-3-surenb@google.com> <20211005184211.GA19804@duo.ucw.cz> <20211005200411.GB19804@duo.ucw.cz> <6b15c682-72eb-724d-bc43-36ae6b79b91a@redhat.com> <192438ab-a095-d441-6843-432fbbb8e38a@redhat.com> X-Mailer: Sylpheed 3.5.1 (GTK+ 2.24.31; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Authentication-Results: imf27.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=korg header.b=sy3Id8Xw; spf=pass (imf27.hostedemail.com: domain of akpm@linux-foundation.org designates 198.145.29.99 as permitted sender) smtp.mailfrom=akpm@linux-foundation.org; dmarc=none X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: 34C0670148DD X-Stat-Signature: mjfz9op9b3f9c91gjk97oz1b6p66dimx X-HE-Tag: 1633573771-901160 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 Wed, 6 Oct 2021 08:20:20 -0700 Suren Baghdasaryan wrote: > On Wed, Oct 6, 2021 at 8:08 AM David Hildenbrand wrote: > > > > On 06.10.21 17:01, 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. > > > > Valuable information > > Yeah, I should have described it clearer the first time around. If it gets this fancy then the 80 char limit is likely to become a significant limitation and the choice should be explained & justified. Why not 97? 1034? Why not just strndup_user() and be done with it? > > My question would be, if we really have to expose these strings to the > > kernel, or if an id is sufficient. Sure, it would move complexity to > > user space, but keeping complexity out of the kernel is usually a good idea. > > My worry here is not the additional complexity on the userspace side > but the performance hit we would have to endure due to these > conversions. Has the performance hit been quantified? I've seen this many times down the ages. Something which *could* be done in userspace is instead done in the kernel because coordinating userspace is Just So Damn Hard. I guess the central problem is that userspace isn't centrally coordinated. I wish we were better at this.