Received: by 2002:a05:6a10:d5a5:0:0:0:0 with SMTP id gn37csp2510130pxb; Fri, 8 Oct 2021 09:11:52 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzbymHgUuFXt7Ub5vbXDRuGvcRjxW1i96tXoKvKSDxvHxqIghpVDFQ8aasdh355sL3Ghnux X-Received: by 2002:a62:9242:0:b0:446:5771:7901 with SMTP id o63-20020a629242000000b0044657717901mr11186013pfd.81.1633709512471; Fri, 08 Oct 2021 09:11:52 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1633709512; cv=none; d=google.com; s=arc-20160816; b=ZcLpzHuqOn3846OUHZPp2T/8Ce0SldtiSchOsqyBHHSbIoi0Va5VKaphLnrLLPo1OI rePy8oKuqtBwr0q5ycuisy1rc5uCItO5i2edzLq7PiYBmIftnzfxk9/tzpHTkAYQI7Wz QEswfG3tqyprzKBQL1MMH4x/Kt20xy0MRm2eGrgsy53daxnS5w78PNYj7m1yMOu5mRjo hs/FoZ43T5RcRr2pnDaDDVxbgfs/EZEj9g2DFW11ba09Va9pKazvF2HYJ5rorwX8dnoM X03wR6xB1UfOH7QKwB3jPQNdA0RH8k22TR7K8ikYZtt011SOvS87qkjGu0zfDZh1qYME KANA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=G33pHw0ueNt5fMw+IeGu7bQcs55JybN6lDQyIbd7GiQ=; b=UP1tF3ioBixZ9x815v+2xqIPjVyRIPXF6CIOXXHnIYlOpEQfCHvODHPZcS4YDg4JdL F0ADdIWGEmAxv5RdpWkZGZWHD8DaExzBGMk2g/U1WUQU034Qfro+jdRP8GbghhGaohEi AZBZ4bAdGtDxDHsStwr3q01WxGEGyJc1+qH7ghStZlmzKnbIcFQD3Gp0dTDHB+t1Iih3 lHKV3LY8rWSzNSxS7mtH3E1EO7P4E3mqt1Ob0XOOt+eWHeqhfawUbvUx2rgluEw8QgY1 hWUsec07s/qCw5iu/IvtUkjbZTcOQeZsOtP9gJMwmkAMVpzlWE6FKi+G9SwCnJGctK8r HFZQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b=Bv7ZpFLy; 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; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id e1si3821296pgv.160.2021.10.08.09.11.31; Fri, 08 Oct 2021 09:11:52 -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=@google.com header.s=20210112 header.b=Bv7ZpFLy; 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; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229559AbhJHQMX (ORCPT + 99 others); Fri, 8 Oct 2021 12:12:23 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:42548 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229487AbhJHQMW (ORCPT ); Fri, 8 Oct 2021 12:12:22 -0400 Received: from mail-yb1-xb2e.google.com (mail-yb1-xb2e.google.com [IPv6:2607:f8b0:4864:20::b2e]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id BC7B2C061755 for ; Fri, 8 Oct 2021 09:10:26 -0700 (PDT) Received: by mail-yb1-xb2e.google.com with SMTP id w10so22210149ybt.4 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=VTL4+gxxew/EDfdVvhH3I68gM/VoPAWoFrKEP9UTgJ2XGydh97mzNKh2uHL7lzhqEx /ejanEC+SEcscq8VCZwZXTDpfmYaIq9fdncpMsg8ZId53M9SiCJKoQxvaBH5DdqP/O1l RajH8cU4tiwtQ4YAcwDe65F3POE8qtPELCQ3bXm0dkMhcflwdskm4Vyo8lIe2fpmspCM SgirhxNu2vRqLmX8ANddzUcth5ZCQxiveNNosa8k2E2PHkhUaJTy5wVeWYC5SZw8Xj0k K0j5kjvvXBRbd5W1962WaC+kT6cCz2z1utYz5vC7hoC5Vpf0FC4q8qPrj8OCicgBBEYA b/8g== X-Gm-Message-State: AOAM5322MOQKSiOQlSC2yEby6qmflrTpZp2sq3XRQXInAKK9uCM1t6Zw 2+TGmm1n9Q5/+3dgKx/VoRZj3R1erwrC78pM2+TkOQ== 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" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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