Received: by 2002:a05:6a10:d5a5:0:0:0:0 with SMTP id gn37csp944097pxb; Wed, 6 Oct 2021 19:43:15 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzNu+a25d073rOQ0GnHwbtdeIJY1ozfsUNnmmPhsAswA2LI9oRX3nCrkqDAkggRfJE0+mgQ X-Received: by 2002:a63:da54:: with SMTP id l20mr1308047pgj.341.1633574594853; Wed, 06 Oct 2021 19:43:14 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1633574594; cv=none; d=google.com; s=arc-20160816; b=JtWmiYKp+BMMg6HwxZq0+33YY2wNzjuG4+PAGIyYBwyBF68dRq4FsjQLkxkiQtJ512 M8U5A+qZp1ZDhOYkWthB1loBbKWB0OOO1ButRQXkHHlIl5ANvnXoDSwXvPHtKVdC/aM/ xlKOm9ELHdEvs5YmsJlRM3qpQvDwGJ3KBPS2tfZPoumAgJuuLmK0DrGyLCtwsPGg7L7a 02E4kJ0vMffwPM9iaKuHbhkXlKsL1FVITfgHdV8W3tm8cs+WrWsL9DjHcy6mXqBEyoOk g98siqdMGx2v3c3MxC6Oec/lylxpdGOWKSCJyDPfX6FAAPcv+DEjRMRvsVCKz1d6rO+v xjHg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:subject:cc:to:from:date :dkim-signature; bh=e+0P0HJ0mzxhlXB2WoIWa/iuPPbxSfr/5fIAvwBSe0M=; b=BdSKZJLt/+CW4uM4K8zTjpXl3R+P64/2+JMDPrOH4OMFSdSE11FqeIwDidcBWnNvEH ewv69K5wrfV4NdyE35V9XDnCZqdaLd+9ij+eULD9NMzETrPg4lE+xjfchwP4w/5cSJUB ieblKC9BM8AcJFmDWe3Qv2K2Q1H2RVQuqNnPM/Db0nYEjpBOKeHlRRZPfBAtXOmq0skj bAk8+YKdkq2Upj/9F50guWRCr8g5uJDdp0DskdIO3QtyJxQW8lgSOEwFw03x+PbXCVpI QSGQQLDmT7MCWP1+nHp3jy17/08sekPHA8f1I6nzz2fLAP+wcvO2MhTD5WWLS67bLZIQ Qg9Q== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linux-foundation.org header.s=korg header.b=b7fobYii; 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id pf14si9613740pjb.117.2021.10.06.19.42.50; Wed, 06 Oct 2021 19:43:14 -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=@linux-foundation.org header.s=korg header.b=b7fobYii; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232348AbhJGClg (ORCPT + 99 others); Wed, 6 Oct 2021 22:41:36 -0400 Received: from mail.kernel.org ([198.145.29.99]:41258 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230489AbhJGClf (ORCPT ); Wed, 6 Oct 2021 22:41:35 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id 1586C61076; Thu, 7 Oct 2021 02:39:41 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linux-foundation.org; s=korg; t=1633574382; bh=seB2mDoF7EhQhumx+fQ/P/EBwoDpNc1LmNcHuen000M=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=b7fobYiiYE5BmHhssdbXlDCCnK9i4BgS2A2AR7eh0Icy+AmV6ORxd+Z0gfYYKTU4c j+PZ6YrKt5ns3BCjdre/kwM0aeRQ4KkWUJa2LpIW53Zgyy5qSrmDkqa/72mAkGOZqE vE4eahfl5EH5bOyRZN7wX1KclIuC6Mos9bVfnOoI= Date: Wed, 6 Oct 2021 19:39:40 -0700 From: Andrew Morton To: Suren Baghdasaryan Cc: Colin Cross , Sumit Semwal , Michal Hocko , 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, Chinwen Chang (=?UTF-8?Q?=E5=BC=B5=E9=8C=A6?= =?UTF-8?Q?=E6=96=87?=) , Axel Rasmussen , Andrea Arcangeli , Jann Horn , apopple@nvidia.com, John Hubbard , 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 , Pavel Machek , 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 Subject: Re: [PATCH v10 2/3] mm: add a field to store names for private anonymous memory Message-Id: <20211006193940.c261f21fcd14b4b52aae1fbc@linux-foundation.org> In-Reply-To: References: <20211001205657.815551-1-surenb@google.com> <20211001205657.815551-2-surenb@google.com> <20211001160830.700c36b32b736478000b3420@linux-foundation.org> X-Mailer: Sylpheed 3.5.1 (GTK+ 2.24.31; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, 4 Oct 2021 09:21:42 -0700 Suren Baghdasaryan wrote: > > > > The name pointers are not shared between vmas even if they contain the > > > > same name. The name pointer is stored in a union with fields that are > > > > only used on file-backed mappings, so it does not increase memory usage. > > > > > > > > The patch is based on the original patch developed by Colin Cross, more > > > > specifically on its latest version [1] posted upstream by Sumit Semwal. > > > > It used a userspace pointer to store vma names. In that design, name > > > > pointers could be shared between vmas. However during the last upstreaming > > > > attempt, Kees Cook raised concerns [2] about this approach and suggested > > > > to copy the name into kernel memory space, perform validity checks [3] > > > > and store as a string referenced from vm_area_struct. > > > > One big concern is about fork() performance which would need to strdup > > > > anonymous vma names. Dave Hansen suggested experimenting with worst-case > > > > scenario of forking a process with 64k vmas having longest possible names > > > > [4]. I ran this experiment on an ARM64 Android device and recorded a > > > > worst-case regression of almost 40% when forking such a process. This > > > > regression is addressed in the followup patch which replaces the pointer > > > > to a name with a refcounted structure that allows sharing the name pointer > > > > between vmas of the same name. Instead of duplicating the string during > > > > fork() or when splitting a vma it increments the refcount. > > > > > > Generally, the patch adds a bunch of code which a lot of users won't > > > want. Did we bust a gut to reduce this impact? Was a standalone > > > config setting considered? > > > > I didn't consider a standalone config for this feature because when > > not used it has no memory impact at runtime. As for the image size, I > > built Linus' ToT with and without this patchset with allmodconfig and allnoconfig would be more interesting. People who want small kernels won't be using allmodconfig! > > the sizes are: > > Without the patchset: > > $ size vmlinux > > text data bss dec hex filename > > 40763556 58424519 29016228 128204303 7a43e0f vmlinux > > > > With the patchset: > > $ size vmlinux > > text data bss dec hex filename > > 40765068 58424671 29016228 128205967 7a4448f vmlinux > > > > The increase seems quite small, so I'm not sure if it warrants a > > separate config option. > > Andrew, do you still think we need a separate CONFIG option? I fixed > the build issue when CONFIG_ADVISE_SYSCALLS=n and would like to post > the update but if you want to have a separate config then I can post > that together with the fix. Please let me know. I don't see much downside to the standalone option. More complexity for developers/testers, I guess. But such is life?