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 23338C4332F for ; Thu, 7 Oct 2021 02:47:13 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 078A361260 for ; Thu, 7 Oct 2021 02:47:13 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233378AbhJGCtE (ORCPT ); Wed, 6 Oct 2021 22:49:04 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:37860 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232262AbhJGCtC (ORCPT ); Wed, 6 Oct 2021 22:49:02 -0400 Received: from mail-yb1-xb36.google.com (mail-yb1-xb36.google.com [IPv6:2607:f8b0:4864:20::b36]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id D36C8C061755 for ; Wed, 6 Oct 2021 19:47:09 -0700 (PDT) Received: by mail-yb1-xb36.google.com with SMTP id w10so9973279ybt.4 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=T1m1QU3XIkDJda8Gqh//qm8ZnLFUteR+1bPYqUgbuisEF2fwO+TYalM3ks2QceKC9W Wo5Z7jA/HbvX6px2KKebbIkOQCuA7EYe7s90yK2go8TxoTmoCYuVRDXrhsdjCbPQie59 mIJCeqC9L8wlLmzUbTwdgXG9uueZbCHStPic2Vfrq8SxAeTPUtEAolLngf0ob1+P4iQ6 T12y4PmJhgt0cc4YQ6VAqZFhR44EKUp6vCFAaQ0khm9KHP+R5WQj0fnN/6UexDn8WSM8 ZWb6FhmITrVxZgIve19ahwPAhvT2PY/bVJbUYQ8u8tmPaCe1vN+M0zUnRBXMw4/OBWLo dJ/w== X-Gm-Message-State: AOAM530UZj5MFnV2yTLzeA+qXQO2RrWzB1k6QCDHsdDmCNOz/qfOJEH7 tzFWAroOnK0U9CrxfPvlozZnU5WjpbAAQgmnO7mNlQ== 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" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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. >