Received: by 2002:a05:6a10:d5a5:0:0:0:0 with SMTP id gn37csp937718pxb; Wed, 6 Oct 2021 19:31:28 -0700 (PDT) X-Google-Smtp-Source: ABdhPJw+JsnptCeCgAaJBIrSxS+naVEeaZU18kl+kSanItqRT86fPx10AzU+T/B//C6ZN9rnP0UT X-Received: by 2002:aa7:db17:: with SMTP id t23mr2496058eds.75.1633573888552; Wed, 06 Oct 2021 19:31:28 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1633573888; cv=none; d=google.com; s=arc-20160816; b=JiJ4pDpOJPnlWl7BhIFg0J1ESu7O52jjz9jnRQHLaSdYbXo+YQgAPTXn0O2qAGdhQW n/lf4y31zlWh4oaJFn7quMtQTNMpERriIPK3ihNyFmGG6GZXvgXG6kd/F5tEsXPIU5cb 5nhzx4ZAmaMF1AKOh+pBwcYs8ETvzuMFz4P851KYrbkctsZprB+corsOj0C9nfoqN5a9 9kGSMLFmlivT1D2mUd/k1gJPvNr05N/Pysdvy7CXtWlKAFDaXa69jUwOoERVrh4iqQ3Y VshJQzcNbcJr8IKWOfpH3Qbp+OZKDz9x5CYgnDTG2rFxIpVm9xwzoZ1gYVv2CkLfReLD IPNA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:subject:cc:to:from:date :dkim-signature; bh=CYYAEOOB/IFhrdr3EfWGZm81xFQxG3o9RfGM5g/TMIg=; b=Ku5+IJwiryPM7AZF3Kd8xJM4vnj4wvBXuklplYUFGCCkzS3XlABWZuno5mFPOogpf1 L52GZl5NFa4an0VkHyClJcbzDfsoLdK1S9AQTYF4dROa3xwcsfpvoGs6xe+tzp8Hwqce 34uZdQvyhV8K/hcaXBiebvdxV8XnyKA2wrPcJan7e5Urk9QF2eXgQAv/TRyz4JPmnB1Z eY/ztTFZeN+P7aDXwPbANwBTGPuqL5UG2exoH9YWwzYi0ZDYNkRTeBqFm7sYPaMBhA+Z xVs4B5P+wfbtSygqdXcHewv2LGA9DPyDIrmaBpboh9qVxMfFEgg16WRZLfYcsFu5Wvr2 rxFA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linux-foundation.org header.s=korg header.b=sy3Id8Xw; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id ds17si18313694ejc.79.2021.10.06.19.31.04; Wed, 06 Oct 2021 19:31:28 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@linux-foundation.org header.s=korg header.b=sy3Id8Xw; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232298AbhJGCbX (ORCPT + 99 others); Wed, 6 Oct 2021 22:31:23 -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.