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 21B5FC433EF for ; Thu, 7 Oct 2021 02:29:34 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 039F361245 for ; Thu, 7 Oct 2021 02:29:33 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232346AbhJGCbY (ORCPT ); Wed, 6 Oct 2021 22:31:24 -0400 Received: from mail.kernel.org ([198.145.29.99]:38384 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230489AbhJGCbW (ORCPT ); Wed, 6 Oct 2021 22:31:22 -0400 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 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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.