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 905C4C433F5 for ; Thu, 7 Oct 2021 08:47:38 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id F383761163 for ; Thu, 7 Oct 2021 08:47:37 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org F383761163 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=rasmusvillemoes.dk Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kvack.org Received: by kanga.kvack.org (Postfix) id 83E5E6B006C; Thu, 7 Oct 2021 04:47:37 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 7EEE96B0071; Thu, 7 Oct 2021 04:47:37 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 68F5F900002; Thu, 7 Oct 2021 04:47:37 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0119.hostedemail.com [216.40.44.119]) by kanga.kvack.org (Postfix) with ESMTP id 579DD6B006C for ; Thu, 7 Oct 2021 04:47:37 -0400 (EDT) Received: from smtpin05.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id E2475183459DC for ; Thu, 7 Oct 2021 08:47:36 +0000 (UTC) X-FDA: 78669012912.05.C373120 Received: from mail-lf1-f47.google.com (mail-lf1-f47.google.com [209.85.167.47]) by imf09.hostedemail.com (Postfix) with ESMTP id 54D1630008D2 for ; Thu, 7 Oct 2021 08:47:36 +0000 (UTC) Received: by mail-lf1-f47.google.com with SMTP id y26so22033297lfa.11 for ; Thu, 07 Oct 2021 01:47:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rasmusvillemoes.dk; s=google; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=adlW7pivg4cyteV3mlsXKz5Do/ag2vJ2th3mLW+Jmhk=; b=NWv2fnZXyOmBKQNz9D7DBaxjTucq2XfkEMTsgzUE8HR+WVOhbVAUU4xS7nXJRwqJF8 g3q1WrbffIpNZTnYHCkKMDKRrc3rJ2PvfatVUE2Uw1i6BVBTwiccMxMJj/YAMu2MuKJ7 9XEcOXAoCIocfpPBryXu5bKAKs+AlDSqnYUtA= 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:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=adlW7pivg4cyteV3mlsXKz5Do/ag2vJ2th3mLW+Jmhk=; b=lg5c7+71GnOUEusVAn5ujoo0/1ANbzm6nkcEegyALJi4sB9yLyXl/I6tXmTcs5zFQp ph38uRAcU9iM6yE+xnO4mt0FfL4I3ywQJkDaW04wjDKHPdqTnC+Ek31h/N+p/JgDUaR3 bujENd+CjSQhVDkQ1OB362InzJnbQPoz1h2/DEgFs+wmU0RFhRAIDwhSCz3tiylZ26mR vA63f7XI+gia4l+aCvqF2Z9bXH+bma/5Mx2u7t8T4DYsTWuERmtpglYvxnKJPD3+TWdC oOPHxl1g4VxLxF2BCVgGziZ4AocXKZB6d116hUjWdhdmHSUDhzxIznst9Ml6OpW6n2Bj P+Ig== X-Gm-Message-State: AOAM530gCg73gYia1JLXlTSF8QxaS3f4INZGA9Lh1uEUf3BssR4nlyL1 /OeSeaC36ONnUiytBeCM+REOlQ== X-Google-Smtp-Source: ABdhPJzsYPt+vLAs50hdpyaFOkVRdocmTQrfybHrq0Gm27Ezn/kTFNFcWG+99jNjVDI1tjzVTzjMvw== X-Received: by 2002:a05:6512:228f:: with SMTP id f15mr2982523lfu.253.1633596454456; Thu, 07 Oct 2021 01:47:34 -0700 (PDT) Received: from [172.16.11.1] ([81.216.59.226]) by smtp.gmail.com with ESMTPSA id l23sm2716647ljg.99.2021.10.07.01.47.32 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 07 Oct 2021 01:47:34 -0700 (PDT) Subject: Re: [PATCH v10 3/3] mm: add anonymous vma name refcounting To: Michal Hocko , Suren Baghdasaryan Cc: Pavel Machek , David Hildenbrand , 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, LKML , linux-fsdevel@vger.kernel.org, linux-doc@vger.kernel.org, linux-mm , kernel-team References: <20211005184211.GA19804@duo.ucw.cz> <20211005200411.GB19804@duo.ucw.cz> <6b15c682-72eb-724d-bc43-36ae6b79b91a@redhat.com> <20211006175821.GA1941@duo.ucw.cz> From: Rasmus Villemoes Message-ID: <92cbfe3b-f3d1-a8e1-7eb9-bab735e782f6@rasmusvillemoes.dk> Date: Thu, 7 Oct 2021 10:47:31 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: 54D1630008D2 X-Stat-Signature: zrx3b7qzzyi1gtujb5akmd4r315m6ypn Authentication-Results: imf09.hostedemail.com; dkim=pass header.d=rasmusvillemoes.dk header.s=google header.b=NWv2fnZX; dmarc=none; spf=pass (imf09.hostedemail.com: domain of linux@rasmusvillemoes.dk designates 209.85.167.47 as permitted sender) smtp.mailfrom=linux@rasmusvillemoes.dk X-HE-Tag: 1633596456-630759 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 07/10/2021 10.10, Michal Hocko wrote: > On Wed 06-10-21 11:18:31, Suren Baghdasaryan wrote: >> On Wed, Oct 6, 2021 at 10:58 AM Pavel Machek wrote: > [...] >>> 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. > > I believe Pavel meant something as simple as > $ YOUR_FILE=$YOUR_IDS_DIR/my_string_name > $ touch $YOUR_FILE > $ stat -c %i $YOUR_FILE So in terms of syscall overhead, that would be open(..., O_CREAT | O_CLOEXEC), fstat(), close() - or one could optimistically start by doing a single lstat() if it is normal that the name is already created (which I assume). As for the consumer, one can't directly map an inode number to a dentry, but whoever first creates the name->id mapping could also be responsible for doing a "sprintf(buf, "/id/to/name/%016lx", id); symlink(name, buf)". And if one did the optimistic lstat() succesfully, one would know that someone else created the file and thus the symlink. And since the operations are idempotent, the obvious races are irrelevant. Then the consumer would only need to do a readlink() to get the name. But that would only be for presentation to a human. Internally all the aggregation based on the type of anon mem the tool might as well do in terms of the integer id. > YOUR_IDS_DIR can live on a tmpfs and you can even implement a policy on > top of that (who can generate new ids, gurantee uniqness etc...). > > The above is certainly not for free of course but if you really need a > system wide consistency when using names then you need some sort of > central authority. How you implement that is not all that important > but I do not think we want to handle that in the kernel. IDK. If the whole thing could be put behind a CONFIG_ knob, with _zero_ overhead when not enabled (and I'm a bit worried about all the functions that grow an extra argument that gets passed around), I don't mind the string interface. But I don't really have a say either way. Rasmus