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 47040C433FE for ; Wed, 6 Oct 2021 18:18:45 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id D7B7F610A5 for ; Wed, 6 Oct 2021 18:18:44 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org D7B7F610A5 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 6DBF1900002; Wed, 6 Oct 2021 14:18:44 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 686C66B0071; Wed, 6 Oct 2021 14:18:44 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 54DFC900002; Wed, 6 Oct 2021 14:18:44 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0064.hostedemail.com [216.40.44.64]) by kanga.kvack.org (Postfix) with ESMTP id 42EA06B006C for ; Wed, 6 Oct 2021 14:18:44 -0400 (EDT) Received: from smtpin01.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id AF5112FDEE for ; Wed, 6 Oct 2021 18:18:43 +0000 (UTC) X-FDA: 78666823326.01.585A5FA Received: from mail-yb1-f176.google.com (mail-yb1-f176.google.com [209.85.219.176]) by imf29.hostedemail.com (Postfix) with ESMTP id 6906C9013A60 for ; Wed, 6 Oct 2021 18:18:43 +0000 (UTC) Received: by mail-yb1-f176.google.com with SMTP id w10so7500067ybt.4 for ; Wed, 06 Oct 2021 11:18:43 -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=tS0Q/doPfkgcSn/P1ry79XfUH0i7iJLfycZHaCEByaw=; b=TYlphAvwMJftzt6RU5u9b6mLtXkIqYWFA04tNKYd2B2kJaBNHrvFS+iWcxQyx65O49 VEw0jFjeBxrJigtMkEwMctb8oSbx+fuz5GPExgicIXWNFArloubetA2TV3UEBOxGB59S 4/eOuXBnAvuNH7y8YiILc6KY9YVEnat4qn2XUv33xrzz3GJLMCPCjq1bI/veMmjJStMA mw1RSKpfndHUtx7NSTXL90xYj4QC8EJDHuoNRRjBjJoyYzyw7iirxJ6l/qIOOS8/aEEI zLEZyLx56Nk0A1AScwAL4V61zvIuQvil+E41AYH4QmyoGC+u+esm8H+BU3U5aLJkJiKd +gpw== 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=tS0Q/doPfkgcSn/P1ry79XfUH0i7iJLfycZHaCEByaw=; b=pE8cjJkTfeYrX4ogfexXYm+oJECQqVkAwhVh3469/8fMi0X1yBzW8wgzHMGc3AakwY gcWwo2FwQ0kNYspVBus1TS732+yT+2mgaVbvatpY5QdF9QpZX3PcLhVV4a5pHiGcdxq2 /6mUSoU8vIOmgs+mjDlOxIFBVsVQBJ8Z4vNKl+VPbK26Iyd8XjkxBGh4eGDHHSuRsOJz w2uvYCjY/Ba9YiX52418emiL2v2/c9MZO3xm03eEy+3/7GKqhKSNsB84R7sfK29MEy8p MTZ/WrP93jMsfFkyGqeMAxqxbIFPrRF/NdApPqWou6VpUIa30AA6R2l9o/RfHQbWkwcR GQew== X-Gm-Message-State: AOAM531/jLcWMJBIGSY/7ttnvvOE4wOaRnVLeAANK0qGVXPwGEGGb8ey ixc5uYCIiXsJ5u7ZwqCSH8Dcs+Ipn2oCTlqvgkDwEQ== X-Google-Smtp-Source: ABdhPJxugzCMn7sZu79C5fnZMRKkgBcjmMuKl0Fdq3TPkxzrJccYHRxTws0QUusFhxlrkQ2KrgfrvvthwxjhDBttraA= X-Received: by 2002:a25:552:: with SMTP id 79mr29984731ybf.202.1633544322361; Wed, 06 Oct 2021 11:18:42 -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> <20211006175821.GA1941@duo.ucw.cz> In-Reply-To: <20211006175821.GA1941@duo.ucw.cz> From: Suren Baghdasaryan Date: Wed, 6 Oct 2021 11:18:31 -0700 Message-ID: Subject: Re: [PATCH v10 3/3] mm: add anonymous vma name refcounting To: Pavel Machek Cc: David Hildenbrand , Michal Hocko , John Hubbard , Andrew Morton , 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, =?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, Rasmus Villemoes , LKML , linux-fsdevel@vger.kernel.org, linux-doc@vger.kernel.org, linux-mm , kernel-team Content-Type: text/plain; charset="UTF-8" X-Rspamd-Server: rspam03 X-Rspamd-Queue-Id: 6906C9013A60 X-Stat-Signature: zt7zc5b67oskzzstaxpyrsrqq9hp976n Authentication-Results: imf29.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=TYlphAvw; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf29.hostedemail.com: domain of surenb@google.com designates 209.85.219.176 as permitted sender) smtp.mailfrom=surenb@google.com X-HE-Tag: 1633544323-195235 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 10:58 AM Pavel Machek wrote: > > Hi! > > > > 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. > > I'd be careful; if you allow special characters like that, you will > confuse some kind of parser. That's why I think having a separate config option with default being disabled would be useful here. It can be enabled on the systems which handle [anon:...] correctly without affecting all other systems. > > > Packages are constantly evolving, new ones are developed, names can > > change, etc. So assigning a unique id for these names is not really > > feasible. > > That leaves us with the central facility option, which as I described > > in my previous email would be prohibitive from performance POV (IPC > > every time we have a new name or want to convert id to name). > > That "central facility" option can be as simple as "mkdir > /somewhere/sanitized_id", using inode numbers for example. You don't > really need IPC. Hmm, so the suggestion is to have some directory which contains files representing IDs, each containing the string name of the associated vma? Then let's say we are creating a new VMA and want to name it. We would have to scan that directory, check all files and see if any of them contain the name we want to reuse the same ID. This is while we are doing mmap() call, which is often a part of time sensitive operation (for example app is starting and allocating some memory to operate). App startup time is one of the main metrics our users care about and regressing that would not go well with our QA team. > > Plus, I don't really believe the IPC cost would be prohibitive. This option was discussed by the Android performance team and rejected 8 years ago. The problem is that these operations are often happening in performance-sensitive areas of the process lifecycle. > > Or you could simply hash the string and use the hash as id... I don't see how this would help. You still need to register your hash->name association somewhere for that hash to be converted back to the name. Did I misunderstand your suggestion? > > Best regards, > Pavel > -- > http://www.livejournal.com/~pavelmachek