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 09F36C433FE for ; Fri, 8 Oct 2021 16:10:29 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 8A94261073 for ; Fri, 8 Oct 2021 16:10:28 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 8A94261073 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 8F3716B006C; Fri, 8 Oct 2021 12:10:27 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 87BE96B0071; Fri, 8 Oct 2021 12:10:27 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 6CDF6900002; Fri, 8 Oct 2021 12:10:27 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0139.hostedemail.com [216.40.44.139]) by kanga.kvack.org (Postfix) with ESMTP id 5AD016B006C for ; Fri, 8 Oct 2021 12:10:27 -0400 (EDT) Received: from smtpin08.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id 0551A1846CA3D for ; Fri, 8 Oct 2021 16:10:27 +0000 (UTC) X-FDA: 78673757694.08.2D425AF Received: from mail-yb1-f172.google.com (mail-yb1-f172.google.com [209.85.219.172]) by imf22.hostedemail.com (Postfix) with ESMTP id B44E52848 for ; Fri, 8 Oct 2021 16:10:26 +0000 (UTC) Received: by mail-yb1-f172.google.com with SMTP id a7so22215658yba.6 for ; Fri, 08 Oct 2021 09:10:26 -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=G33pHw0ueNt5fMw+IeGu7bQcs55JybN6lDQyIbd7GiQ=; b=Bv7ZpFLyYPApZxpHNAgAUvso133HjrOBFL6hqMdB+IrVyL/rHGAOU/y+005qkEd0nu ZA5PlXGDWJ2Oy1ZLhPo2KEUzS+ThRbdjQdMeRAA9WpFraOCBVrlry8zMBToM1RUBboE3 oFia/EYFHpnczvwhehgCq2Sry06QgR/xMNSmDGcjYnj6SRqQjyqqIrHj+cKXq871uvd1 GbC91qH7oND33Xt1APC2G4qAdHiZb1fgN7SnJgNXjtbZMyZTbybzZtPoc/PK13IDvWmZ FkAucL5pN+akLtMwvcAkApQv0AUabZqXSsvJl2QYJeLcTOSME8Ak4XCwwK7RUdavPe+E a8Pw== 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=G33pHw0ueNt5fMw+IeGu7bQcs55JybN6lDQyIbd7GiQ=; b=kbjC9ZpnTB8qe6zMLUpqVtF0DfwDbCcQgreMhFBlWft7tIGKsyBN7tXDV1LtuxyaPp 7edPzHydlFaBpPiAGCCstrNa76fCetD7mDgysolmBv7wsfS8ErbSMkZa0ctN6JWl2yes 53AvIJRkIjSEzTVi76e8zK/Hhac6sFnllHvaMfcl6GRm6yNbWoVp+VgWzTqe9RvrhYTH n7+l+C1M1dod1ODkN8wBnEUN1kBTSEtN/ipqxspeLx0fK/QOJ4fcWKdvhnpJQbjnK3xK DZgvnR1UtGenwxPJ07N2I3baIsFCoNSP4hcRnhnwhPG8hhVBnQA7qn+e95hB7OcxRDkK 3QGg== X-Gm-Message-State: AOAM533Z9jzja/m6ufRN0g/U4FJ2L+ubmRE2tZ5+7gQcZIitq/giaCMz r2U1/X3nYjf+er0byzbTVLmYyD7uBBpdw6M6z9swWQ== X-Google-Smtp-Source: ABdhPJxCL/oJpeRH39HJsnbtpduvh2CejVR6+QmWEnNfuUXcZUpgiTakWbEdOxd31P0xMuAIf32tWZVuGngf1ObyV/M= X-Received: by 2002:a05:6902:120e:: with SMTP id s14mr4989108ybu.161.1633709425599; Fri, 08 Oct 2021 09:10:25 -0700 (PDT) MIME-Version: 1.0 References: <92cbfe3b-f3d1-a8e1-7eb9-bab735e782f6@rasmusvillemoes.dk> <20211007101527.GA26288@duo.ucw.cz> <202110071111.DF87B4EE3@keescook> <4a1dd04f-eda3-5c71-4772-726fd6fa2a38@intel.com> In-Reply-To: From: Suren Baghdasaryan Date: Fri, 8 Oct 2021 09:10:14 -0700 Message-ID: Subject: Re: [PATCH v10 3/3] mm: add anonymous vma name refcounting To: Michal Hocko Cc: Dave Hansen , Kees Cook , Pavel Machek , Rasmus Villemoes , David Hildenbrand , John Hubbard , Andrew Morton , Colin Cross , Sumit Semwal , 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, =?UTF-8?B?Q2hpbndlbiBDaGFuZyAo5by16Yym5paHKQ==?= , 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, LKML , linux-fsdevel@vger.kernel.org, linux-doc@vger.kernel.org, linux-mm , kernel-team , timmurray@google.com Content-Type: text/plain; charset="UTF-8" X-Rspamd-Server: rspam01 X-Rspamd-Queue-Id: B44E52848 X-Stat-Signature: q5fqgjjmm1kbz8a9effa4jhik8kz3ykm Authentication-Results: imf22.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=Bv7ZpFLy; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf22.hostedemail.com: domain of surenb@google.com designates 209.85.219.172 as permitted sender) smtp.mailfrom=surenb@google.com X-HE-Tag: 1633709426-651835 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 Fri, Oct 8, 2021 at 7:57 AM Michal Hocko wrote: > > On Fri 08-10-21 07:14:58, Dave Hansen wrote: > > On 10/7/21 11:34 PM, Michal Hocko wrote: > > >> Yes, please. It really seems like the folks that are interested in this > > >> feature want strings. (I certainly do.) > > > I am sorry but there were no strong arguments mentioned for strings so > > > far. > > > > The folks who want this have maintained an out-of-tree patch using > > strings. They've maintained it for the better part of a decade. I > > don't know how widely this shipped in the Android ecosystem, but I > > suspect we're talking about billions of devices. Right? Correct. > > > > This is a feature that, if accepted into mainline, will get enabled and > > used on billions of devices. If we dumb this down to integers, it's not > > 100% clear that it _will_ get used. Not as is and not with some major changes in the userspace, which relied on a simple interface: set a name to a vma, observe that name in the /proc/$pid/maps. > > > > That's a pretty strong argument in my book, even if the contributors > > have difficulty articulating exactly why they want strings. > > I would agree that if integers would make this unusable then this would > be a strong argument. But I haven't really heard any arguments like that > so far. I have heard about IPC overhead and other speculations that do > not seem really convincing. We shouldn't hand wave concerns regarding > the implementation complexity and resource handling just by "somebody > has been using this for decates", right? > > Do not get me wrong. This is going to become a user interface and we > will have to maintain it for ever. As such an extra scrutiny has to be > applied. I don't know how to better articulate this. IPC transactions on Android cannot be scheduled efficiently. We're going to have to stall after mmap, make binder transaction, schedule a new process, get the ID, make binder reply, schedule back to the original thread, resume. Doing this potentially for every mmap is a non-starter. Deferring this job is possible but we still have to do all this work, so it still requires cpu cycles and power, not mentioning the additional complexity in the userspace. I'm adding a rep from the performance team, maybe Tim can explain this better. There were a couple suggestions on using filesystem/memfd for naming purposes which I need to explore but if that works the approach will likely not involve any IDs. We want human-readable names in the maps file, not a number. Thanks for all the feedback and ideas! > -- > Michal Hocko > SUSE Labs