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 kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id D1A1CC4332F for ; Tue, 8 Nov 2022 18:45:39 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 746516B0072; Tue, 8 Nov 2022 13:45:39 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 6F62C8E0003; Tue, 8 Nov 2022 13:45:39 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 5BE758E0002; Tue, 8 Nov 2022 13:45:39 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 4B7B46B0072 for ; Tue, 8 Nov 2022 13:45:39 -0500 (EST) Received: from smtpin21.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id F3C371A1282 for ; Tue, 8 Nov 2022 18:45:38 +0000 (UTC) X-FDA: 80111153556.21.232E059 Received: from mail-ej1-f53.google.com (mail-ej1-f53.google.com [209.85.218.53]) by imf30.hostedemail.com (Postfix) with ESMTP id 80AA18000B for ; Tue, 8 Nov 2022 18:45:37 +0000 (UTC) Received: by mail-ej1-f53.google.com with SMTP id f27so40997597eje.1 for ; Tue, 08 Nov 2022 10:45:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=soleen.com; s=google; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=34xmTXahX9JOxAWp+niqcaXhO5EjSMmbu9kacIdY9GA=; b=Q7EEEYcV7XltPOfTeY+7k0wa4jo3dxm2gU1pfbspEfsVW158MhXaCQ2w7LENlv2KFN gbETXxIpwN02DzJ3Dmrp5CaxshdelWH/bKAo2om0M9pxffzXRe+udF/qr5Gbuy8Ut7zW y1aCjGRCgHWuU/JLiaKbIcpaAY6ZoCC703xNcA5l5GhztkTg/WRD22wVzrtpr3R9+SJy hEz5KtX/mhLD38qg/RPQITzxPITBH5tTUAgNObi+6TpUyjh0HGiT54mAXQ1X7/od6THg CeCrxGEiqgEzHBC6z8Sh9TDpLwOXI7kbUTgVTVSeYreXRsyw/ELOmlUegRQBCPB5RCio E/LQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=34xmTXahX9JOxAWp+niqcaXhO5EjSMmbu9kacIdY9GA=; b=F2cUSIdWqje5Jn5bbSOjcHG6Una9MELuT1uyYvWS+30ckOdQRqAJsxtWBmkPa84HGU Q3XS4d+SgeEbdK6FUXgUipIgk/zGVP4cJprWUIWQjV7RGDD7KJJY4GQX7cvo9WuEGlFW lWm85WYX8P8rq3CAn3hxjArqCaqsC29w+Agd+ousyxD8fjLDVZCTeFPTWFRRv9y54jdA lTMr8QHOVP8xIGuppP8gZ6TU7hHQ8kXUB9X+xzTUDY5Lkhifz4XiOgo54qcIF/fJCy31 /tU7AdVYQQSv5mav6n7OpseTO1AzCPnkiKAPzGKsxSr6zFDoY4nTUalL5zn09RpggzZ9 m22g== X-Gm-Message-State: ACrzQf0+hm/l76dKNdUmoMwlbyK0k/q9Ar94yE+13Mbn0v6NbUkkLbQ6 dJ9b4qTzFXVTElTJCLI15iujpkQLr9XIHqRZh3WsMw== X-Google-Smtp-Source: AMsMyM7Tlc8spRalg0u2yiOeDWCAOkwjTndgzLLthoZ/7CAUKa/Ts8f5EjNK5MHh7Os/q7EA89e+nwpl5t2NZIebdhw= X-Received: by 2002:a17:907:761b:b0:7a3:86dd:d330 with SMTP id jx27-20020a170907761b00b007a386ddd330mr53730091ejc.34.1667933135949; Tue, 08 Nov 2022 10:45:35 -0800 (PST) MIME-Version: 1.0 References: <20221107184715.3950621-1-pasha.tatashin@soleen.com> In-Reply-To: From: Pasha Tatashin Date: Tue, 8 Nov 2022 13:44:58 -0500 Message-ID: Subject: Re: [PATCH v2] mm: anonymous shared memory naming To: David Hildenbrand Cc: corbet@lwn.net, akpm@linux-foundation.org, hughd@google.com, hannes@cmpxchg.org, vincent.whitchurch@axis.com, seanjc@google.com, rppt@kernel.org, shy828301@gmail.com, paul.gortmaker@windriver.com, peterx@redhat.com, vbabka@suse.cz, Liam.Howlett@oracle.com, ccross@google.com, willy@infradead.org, arnd@arndb.de, cgel.zte@gmail.com, yuzhao@google.com, linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-doc@vger.kernel.org, linux-mm@kvack.org, bagasdotme@gmail.com, kirill@shutemov.name Content-Type: text/plain; charset="UTF-8" ARC-Authentication-Results: i=1; imf30.hostedemail.com; dkim=pass header.d=soleen.com header.s=google header.b=Q7EEEYcV; spf=pass (imf30.hostedemail.com: domain of pasha.tatashin@soleen.com designates 209.85.218.53 as permitted sender) smtp.mailfrom=pasha.tatashin@soleen.com; dmarc=none ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1667933137; a=rsa-sha256; cv=none; b=568tWJ6uQvKn4L3bV6c+aHvb1vP6E3og/z9nbVQmVgOrIKZoPceuGsuBKu+kcj6DsX0kRq CVhPdMk0uRKWRDj35LDVsYtP70jhIcjruTu+J36OtIAiX1u+KPlB2h0wZJAm9Y+9vHciNF +fkJ8RjxNWK076V1xTm93sRocNQ0OZE= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1667933137; h=from:from:sender: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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=34xmTXahX9JOxAWp+niqcaXhO5EjSMmbu9kacIdY9GA=; b=QWoPu9zsKuEEpeuYHbo75l5blIUeYxq8ISp7EH5NPiPblG5jjO4Rb4iTPMRVIEIge92h34 TO4WVOI+/gxIdIQIx5Wv9S0jJuDIJnGC353g/VIkGNweC3hLvmDUmA+VVUYl4FZElFX9ux uMtdMIz0Ywbc69aTL5PhvflGj8dCejU= X-Stat-Signature: 8f9sse317gqqsnrjpgeb9swuw47ueh5j X-Rspamd-Queue-Id: 80AA18000B Authentication-Results: imf30.hostedemail.com; dkim=pass header.d=soleen.com header.s=google header.b=Q7EEEYcV; spf=pass (imf30.hostedemail.com: domain of pasha.tatashin@soleen.com designates 209.85.218.53 as permitted sender) smtp.mailfrom=pasha.tatashin@soleen.com; dmarc=none X-Rspam-User: X-Rspamd-Server: rspam06 X-HE-Tag: 1667933137-52513 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: Hi David, Thank you for taking a look at this change: On Tue, Nov 8, 2022 at 12:56 PM David Hildenbrand wrote: > > On 07.11.22 19:47, Pasha Tatashin wrote: > > Since: commit 9a10064f5625 ("mm: add a field to store names for private > > anonymous memory"), name for private anonymous memory, but not shared > > anonymous, can be set. However, naming shared anonymous memory just as > > ^ is > OK > > useful for tracking purposes. > > > > Extend the functionality to be able to set names for shared anon. > > > > Sample output: > > /* Create shared anonymous segmenet */ > > s/segmenet/segment/ Ok > > > anon_shmem = mmap(NULL, SIZE, PROT_READ | PROT_WRITE, > > MAP_SHARED | MAP_ANONYMOUS, -1, 0); > > /* Name the segment: "MY-NAME" */ > > rv = prctl(PR_SET_VMA, PR_SET_VMA_ANON_NAME, > > anon_shmem, SIZE, "MY-NAME"); > > > > cat /proc//maps (and smaps): > > 7fc8e2b4c000-7fc8f2b4c000 rw-s 00000000 00:01 1024 [anon_shmem:MY-NAME] > > What would it have looked like before? Just no additional information? Before: 7fc8e2b4c000-7fc8f2b4c000 rw-s 00000000 00:01 1024 /dev/zero (deleted) Pasha > > > > > Signed-off-by: Pasha Tatashin > > --- > > > [...] > > > diff --git a/include/linux/mm.h b/include/linux/mm.h > > index 8bbcccbc5565..06b6fb3277ab 100644 > > --- a/include/linux/mm.h > > +++ b/include/linux/mm.h > > @@ -699,8 +699,10 @@ static inline unsigned long vma_iter_addr(struct vma_iterator *vmi) > > * paths in userfault. > > */ > > bool vma_is_shmem(struct vm_area_struct *vma); > > +bool vma_is_anon_shmem(struct vm_area_struct *vma); > > #else > > static inline bool vma_is_shmem(struct vm_area_struct *vma) { return false; } > > +static inline bool vma_is_anon_shmem(struct vm_area_struct *vma) { return false; } > > #endif > > > > int vma_is_stack_for_current(struct vm_area_struct *vma); > > diff --git a/include/linux/mm_types.h b/include/linux/mm_types.h > > index 500e536796ca..08d8b973fb60 100644 > > --- a/include/linux/mm_types.h > > +++ b/include/linux/mm_types.h > > @@ -461,21 +461,11 @@ struct vm_area_struct { > > * For areas with an address space and backing store, > > * linkage into the address_space->i_mmap interval tree. > > * > > - * For private anonymous mappings, a pointer to a null terminated string > > - * containing the name given to the vma, or NULL if unnamed. > > */ > > - > > - union { > > - struct { > > - struct rb_node rb; > > - unsigned long rb_subtree_last; > > - } shared; > > - /* > > - * Serialized by mmap_sem. Never use directly because it is > > - * valid only when vm_file is NULL. Use anon_vma_name instead. > > - */ > > - struct anon_vma_name *anon_name; > > - }; > > + struct { > > + struct rb_node rb; > > + unsigned long rb_subtree_last; > > + } shared; > > > > So that effectively grows the size of vm_area_struct. Hm. I'd really > prefer to keep this specific to actual anonymous memory, not extending > it to anonymous files. It grows only when CONFIG_ANON_VMA_NAME=y, otherwise it stays the same as before. Are you suggesting adding another config specifically for shared memory? I wonder if we could add a union for some other part of vm_area_struct where anon and file cannot be used together. > Do we have any *actual* users where we don't have an alternative? I > doubt that this is really required. > > The simplest approach seems to be to use memfd instead of MAP_SHARED | > MAP_ANONYMOUS. __NR_memfd_create can be passed a name and you get what > you propose here effectively already. Or does anything speak against it? For our use case the above does not work. We are working on highly paravirtualized virtual machines. The VMM maps VM memory as anonymous shared memory (not private because VMM is sandboxed and drivers are running in their own processes). However, the VM tells back to the VMM how parts of the memory are actually used by the guest, how each of the segments should be backed (i.e. 4K pages, 2M pages), and some other information about the segments. The naming allows us to monitor the effective memory footprint for each of these segments from the host without looking inside the guest. Pasha