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 2F082C433FE for ; Thu, 7 Oct 2021 02:39:46 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id C201661260 for ; Thu, 7 Oct 2021 02:39:45 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org C201661260 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=linux-foundation.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kvack.org Received: by kanga.kvack.org (Postfix) id 1151A900002; Wed, 6 Oct 2021 22:39:45 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 0C5776B0071; Wed, 6 Oct 2021 22:39:45 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id EA939900002; Wed, 6 Oct 2021 22:39:44 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0051.hostedemail.com [216.40.44.51]) by kanga.kvack.org (Postfix) with ESMTP id DA9116B006C for ; Wed, 6 Oct 2021 22:39:44 -0400 (EDT) Received: from smtpin09.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id 89EFB1828A811 for ; Thu, 7 Oct 2021 02:39:44 +0000 (UTC) X-FDA: 78668085888.09.A9AA009 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by imf11.hostedemail.com (Postfix) with ESMTP id 235B1F001D33 for ; Thu, 7 Oct 2021 02:39:44 +0000 (UTC) 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 Authentication-Results: imf11.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=korg header.b=b7fobYii; spf=pass (imf11.hostedemail.com: domain of akpm@linux-foundation.org designates 198.145.29.99 as permitted sender) smtp.mailfrom=akpm@linux-foundation.org; dmarc=none X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: 235B1F001D33 X-Stat-Signature: qgy8msif4zsffk9j93sporez81uyun1h X-HE-Tag: 1633574384-539471 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 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?