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 4D311C43217 for ; Thu, 7 Oct 2021 07:33:20 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id EC5D661248 for ; Thu, 7 Oct 2021 07:33:19 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org EC5D661248 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=redhat.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kvack.org Received: by kanga.kvack.org (Postfix) id 58470900002; Thu, 7 Oct 2021 03:33:19 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 50DBA6B0071; Thu, 7 Oct 2021 03:33:19 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 3ADEC900002; Thu, 7 Oct 2021 03:33:19 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0216.hostedemail.com [216.40.44.216]) by kanga.kvack.org (Postfix) with ESMTP id 252876B006C for ; Thu, 7 Oct 2021 03:33:19 -0400 (EDT) Received: from smtpin40.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id DE12A30C7E for ; Thu, 7 Oct 2021 07:33:18 +0000 (UTC) X-FDA: 78668825676.40.881366F Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [216.205.24.124]) by imf08.hostedemail.com (Postfix) with ESMTP id 8678D3001FF9 for ; Thu, 7 Oct 2021 07:33:18 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1633591998; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=IcGgFJhn+URtM5zX70uUXK5bzpT3Lent47sXcqP2HJM=; b=ilf3mOLAt6xHJ65NPGLnJt46pULByCJX3ELpKnzhlFOfyGL/jq+ZrVzejiqmsO2LWOZVIT vdzkFMtwXHktbgZ1UYf3uvricQu/HR8JXx/LLhPRVDfCgBxCbscit5kkGGL3Qm3tLtyBGW ZMaLXqWr8AffulwA/Q+DRyvqGZsRtnQ= Received: from mail-wr1-f71.google.com (mail-wr1-f71.google.com [209.85.221.71]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-285-jJ0dFBoPPnyNXLlnLoM9bA-1; Thu, 07 Oct 2021 03:33:15 -0400 X-MC-Unique: jJ0dFBoPPnyNXLlnLoM9bA-1 Received: by mail-wr1-f71.google.com with SMTP id k16-20020a5d6290000000b00160753b430fso3965998wru.11 for ; Thu, 07 Oct 2021 00:33:15 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:subject:to:cc:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=IcGgFJhn+URtM5zX70uUXK5bzpT3Lent47sXcqP2HJM=; b=5oWgmC9/tUzafX3heMSsP5v3RWfxCfvXZ3yNK9sxD3MyUWQOgJJ1ly0TqE8MpwZupp fe3Hdj8v7wuMghtHtBd2UxHuMMrrOcTsRgm/1qgrsG0Ef4zYs30aK3zr7aux3eUSVqKN /D8auAtGBa2s5fBL1pMSyQFOmtGDpH5M3YJy/chCHQorYnP96r1tVw2xw7oQLi8MUtf9 oRxpyufLv/0+o5UGd5rS4xMSblKKhmntNmHjuHSoCdYU/S0IPj/14kXov0GzATK56bH9 8AhCf8au6KMRVcdaTwKxz/0VHjFpxLYEJUUE+f+wq9LrcdrhkurtYo0Mx/nVGwnKeCoC X3pg== X-Gm-Message-State: AOAM530QOPrKSZ2up+dUMkkrklmIwm9WTeExWfHFhOWTxcjmrLCeWPx/ UvpB4qcuKwERoodi7J+QywJJQrWNEmR2FZua/fga/G2736rCPNd2iarhatUjfsMrcDasiOV/umh 4+QXvgUQhx5Y= X-Received: by 2002:a1c:7dc8:: with SMTP id y191mr2863357wmc.181.1633591993764; Thu, 07 Oct 2021 00:33:13 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwE8uu5BiQUJRBqH4gg1xzkNu2l2F2J06nqsFu854Q1VUXlrztTCS9j5p/4FyrKQnwZ7WGKOA== X-Received: by 2002:a1c:7dc8:: with SMTP id y191mr2863339wmc.181.1633591993537; Thu, 07 Oct 2021 00:33:13 -0700 (PDT) Received: from [192.168.3.132] (p5b0c6886.dip0.t-ipconnect.de. [91.12.104.134]) by smtp.gmail.com with ESMTPSA id l124sm7732468wml.8.2021.10.07.00.33.11 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 07 Oct 2021 00:33:13 -0700 (PDT) Subject: Re: [PATCH v10 3/3] mm: add anonymous vma name refcounting To: Suren Baghdasaryan Cc: Michal Hocko , John Hubbard , Pavel Machek , 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@oracle.com, 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 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> From: David Hildenbrand Organization: Red Hat Message-ID: Date: Thu, 7 Oct 2021 09:33:10 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Rspamd-Server: rspam03 X-Rspamd-Queue-Id: 8678D3001FF9 X-Stat-Signature: fdau19z9wkdafneqqif56quinsitybbp Authentication-Results: imf08.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=ilf3mOLA; dmarc=pass (policy=none) header.from=redhat.com; spf=none (imf08.hostedemail.com: domain of david@redhat.com has no SPF policy when checking 216.205.24.124) smtp.mailfrom=david@redhat.com X-HE-Tag: 1633591998-316627 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 06.10.21 17:20, 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. > >> >>> Packages are constantly evolving, new ones are developed, names can >>> change, etc. So assigning a unique id for these names is not really >>> feasible. >> >> So, you'd actually want to generate/reserve an id for a given string at >> runtime, assign that id to the VMA, and have a way to match id <-> >> string somehow? > > If we go with ids then yes, that is what we would have to do. > >> That reservation service could be inside the kernel or even (better?) in >> user space. The service could for example de-duplicates strings. > > Yes but it would require an IPC call to that service potentially on > every mmap() when we want to name a mapped vma. This would be > prohibitive. Even on consumption side, instead of just dumping > /proc/$pid/maps we would have to parse the file and convert all > [anon:id] into [anon:name] with each conversion requiring an IPC call > (assuming no id->name pair caching on the client side). mmap() and prctl() already do take the mmap sem in write, so they are not the "most lightweight" operations so to say. We already to have two separate operations, first the mmap(), then the prctl(). IMHO you could defer the "naming" part to a later point in time, without creating too many issues, moving it out of the "hot/performance critical phase" Reading https://lwn.net/Articles/867818/, to me it feels like the use case could live with a little larger delay between the mmap popping up and a name getting assigned. -- Thanks, David / dhildenb