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 BCA80C433FE for ; Thu, 7 Oct 2021 02:47:11 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 3F2B461175 for ; Thu, 7 Oct 2021 02:47:11 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 3F2B461175 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 A0E4F900002; Wed, 6 Oct 2021 22:47:10 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 9C1146B0071; Wed, 6 Oct 2021 22:47:10 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 83759900002; Wed, 6 Oct 2021 22:47:10 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0078.hostedemail.com [216.40.44.78]) by kanga.kvack.org (Postfix) with ESMTP id 750676B006C for ; Wed, 6 Oct 2021 22:47:10 -0400 (EDT) Received: from smtpin21.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id 1A2B28249980 for ; Thu, 7 Oct 2021 02:47:10 +0000 (UTC) X-FDA: 78668104620.21.BE0BAD9 Received: from mail-yb1-f172.google.com (mail-yb1-f172.google.com [209.85.219.172]) by imf28.hostedemail.com (Postfix) with ESMTP id D1E2C9001863 for ; Thu, 7 Oct 2021 02:47:09 +0000 (UTC) Received: by mail-yb1-f172.google.com with SMTP id s4so9937682ybs.8 for ; Wed, 06 Oct 2021 19:47:09 -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=2Cs1bvfp4Te/cba1+QGm30Xc9WLtpDndPuoyLtYCfOA=; b=MygceOBt27vyNNGEqPQPWKuRkZ869tZRG97KZw+qF6zk5ZcPjKugxuSYijToTNPHb5 sHYurBA8Cs8YtaARlyaAoqTpa7S+RaQKEyZK2TfBlzx3raE+YsEFnvEW9WCnztTk7uS4 xyO8HfreUzXFQ89tkC5GhWeCknXB/iFJgrrZ2woMGXTROFMluFEDsfpNEZUIvw+FZhwx 7YDdAIbzbggvSGe9ECRQzEDbTH8tssZN0dIbBCp0AvIJSGh15x8jhsHnCejypdbRR3fy QMVBSDQOooJ62cKwgaSWNKYGs9M4VIVuFE5ruEV6hBdVPbtYWbXhzsSTt+tY8bNNh0ZK /bfQ== 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=2Cs1bvfp4Te/cba1+QGm30Xc9WLtpDndPuoyLtYCfOA=; b=XJmu4iyzCSpWpSXW+1XQ1AbVI4ncIsnV3YM9m3N9kNGHqMnGiGNR3KnkKF/dtwAeqE e9Y8j9QOo57Qt+30/qkVwTDOmaTlu1nw1iZjeEDGKrXQPk/9ZG+PUctxMOJmsy4VsYci 8PyE+nbGcW51XGET03FLnaRfeQGzmdQB7sY2YZ2B+2oLGqElvuozeZTof/Isn64y8h0/ IWfApVKGhB4xB3UkiBdDeG7BqQkABxVGUe9p9tHoMehNs9nekiMy42LwgzbjjMNEhWzl jIIStea2Mz/HJNj4F9XnALh/xp20TXmWnHOZDP57mAVFl2hXR8UdV3IOkjMB3Kn5YmeN zkPw== X-Gm-Message-State: AOAM532VPUeIr+oNhWe6/Ju9K6dpkCVMXFCD9ng6JswWAj8K3X0VdPaJ kzEcT7Nq9YSseFww0gDFoTiSyrrBNb5SiqwUD4L2dA== X-Google-Smtp-Source: ABdhPJxLU8MGnE5SoLyGYG5TTI2jtt2gBV2C+wxkDDL0PUeP0WMegid6aYDJmZhvRMGMzbnJu/NSWMskp6PX5qCRqOQ= X-Received: by 2002:a25:d1d3:: with SMTP id i202mr2002703ybg.487.1633574828693; Wed, 06 Oct 2021 19:47:08 -0700 (PDT) MIME-Version: 1.0 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> <20211006192927.f7a735f1afe4182bf4693838@linux-foundation.org> In-Reply-To: <20211006192927.f7a735f1afe4182bf4693838@linux-foundation.org> From: Suren Baghdasaryan Date: Wed, 6 Oct 2021 19:46:57 -0700 Message-ID: Subject: Re: [PATCH v10 3/3] mm: add anonymous vma name refcounting To: Andrew Morton 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 , 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 , 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 , Tim Murray Content-Type: text/plain; charset="UTF-8" X-Rspamd-Server: rspam02 X-Rspamd-Queue-Id: D1E2C9001863 X-Stat-Signature: yhem5zwnqmw1efgksp1n64ec8nkmb6r4 Authentication-Results: imf28.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=MygceOBt; spf=pass (imf28.hostedemail.com: domain of surenb@google.com designates 209.85.219.172 as permitted sender) smtp.mailfrom=surenb@google.com; dmarc=pass (policy=reject) header.from=google.com X-HE-Tag: 1633574829-375534 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, Oct 6, 2021 at 7:29 PM Andrew Morton wrote: > > 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? The original patch from 8 years ago used 256 as the limit but Rasmus argued that the string content should be human-readable, so 80 chars seems to be a reasonable limit (see: https://lore.kernel.org/all/d8619a98-2380-ca96-001e-60fe9c6204a6@rasmusvillemoes.dk), which makes sense to me. We should be able to handle the 80 char limit by trimming it before calling prctl(). > > > > 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'll try to get the data that was collected or at least an estimate. I imagine collecting such data would require considerable userspace redesign. > 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. It's not just hard, it's also inefficient. And for our usecase performance is important. > > > -- > To unsubscribe from this group and stop receiving emails from it, send an email to kernel-team+unsubscribe@android.com. >