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 487F8C433EF for ; Thu, 7 Oct 2021 02:50:52 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id C92036113E for ; Thu, 7 Oct 2021 02:50:51 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org C92036113E Authentication-Results: mail.kernel.org; dmarc=fail (p=reject dis=none) header.from=google.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kvack.org Received: by kanga.kvack.org (Postfix) id 59CBA6B0071; Wed, 6 Oct 2021 22:50:51 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 525C7900002; Wed, 6 Oct 2021 22:50:51 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 3C6B56B0074; Wed, 6 Oct 2021 22:50:51 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0218.hostedemail.com [216.40.44.218]) by kanga.kvack.org (Postfix) with ESMTP id 2C9DA6B0071 for ; Wed, 6 Oct 2021 22:50:51 -0400 (EDT) Received: from smtpin34.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id EAE162BC3E for ; Thu, 7 Oct 2021 02:50:50 +0000 (UTC) X-FDA: 78668113860.34.55A03C6 Received: from mail-yb1-f180.google.com (mail-yb1-f180.google.com [209.85.219.180]) by imf27.hostedemail.com (Postfix) with ESMTP id A3C38702614B for ; Thu, 7 Oct 2021 02:50:50 +0000 (UTC) Received: by mail-yb1-f180.google.com with SMTP id i84so9899713ybc.12 for ; Wed, 06 Oct 2021 19:50:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=4F/VUUoX5d9pLuj9va8DmcDC9EaYJA0ZhNF6WOHt3n8=; b=W4z+Ot2/rwfvUtqGOA0HqHFoPN/g2j2f12GEa+aPzxsQqWMDUSbzhdbl4QKDrE5ZEH uCF7VIMSREr8EXiPVqrejCQbJSVyY2YfWGFwWBoIrfj/BB6LCd9F9DVskFMoD9Ak5lyQ 7OGOEDa1y4GOfsuzJV8OjddHLK7I2zWWrZ6LX9yavhM0d79aOGcrKB69ETdcrtkCp+vL eTLjv/V9P4VkKOZxo4oydFSm52hqgupfnZYFj3X3H0XUZw+yNpoBAiqlCXntoBX7AveU 1ea1Tcel5OGxJeCtTyf8suXBuuZ9WvU7NB51pCaeC8wreksJH3D5S8qvwFjnytkmgNbt zkjg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=4F/VUUoX5d9pLuj9va8DmcDC9EaYJA0ZhNF6WOHt3n8=; b=lr46mfE8yu6xWz8uJxMm7kUG4lTGf1nhush8U/FPCq5KXEzedoqNtIChvuQoRtr+8G ScXoJbYor1bbjMVIlJMbxr9kXKi9DWZQpM+8wn6VV6BCxvg8bX2DPhBnyGYw4Qjzo6Pl 9c6Z20zgXE+c/hG+s1a8y2oATkJg/vjgRzxCbiKl7+tcumGsSfzp49O2brEiFxBZKTz+ iD4bhI3egLtWTmhx8S0vxBi4KYWQk5ueCVyg9UAOGNH0EY44U4m1SOQzCDQe0Yfyw/me RaNt1DIptgEufBeF+bL3VCRYY/s00TPPJfTIhUhEjOMdbgmefXtP8pTrpxTMyKxmkwFF +wIA== X-Gm-Message-State: AOAM530iPcnp1NJBlBafcRcLIISw6O3zy0S3RA3dzfaEFqsQnsvlrULF rS4ndpKsNRChIjmicrTlkrVVDBPGmUoraKczdP0pAA== X-Google-Smtp-Source: ABdhPJwURhBGwIa2Mo2zsN2z5+HcTIt/J+M1PIauJMogSr896kv94sWKf2q7mONzOcq02flzV/NuzQLkoCDX8/08/9U= X-Received: by 2002:a05:6902:120e:: with SMTP id s14mr2185756ybu.161.1633575049472; Wed, 06 Oct 2021 19:50:49 -0700 (PDT) MIME-Version: 1.0 References: <20211001205657.815551-1-surenb@google.com> <20211001205657.815551-2-surenb@google.com> <20211001160830.700c36b32b736478000b3420@linux-foundation.org> <20211006193940.c261f21fcd14b4b52aae1fbc@linux-foundation.org> In-Reply-To: <20211006193940.c261f21fcd14b4b52aae1fbc@linux-foundation.org> From: Suren Baghdasaryan Date: Wed, 6 Oct 2021 19:50:38 -0700 Message-ID: Subject: Re: [PATCH v10 2/3] mm: add a field to store names for private anonymous memory To: Andrew Morton 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 , 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 , 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 Content-Type: text/plain; charset="UTF-8" X-Rspamd-Server: rspam02 X-Rspamd-Queue-Id: A3C38702614B X-Stat-Signature: i3i61pfghj4febr79cbmtrarz4o1uom9 Authentication-Results: imf27.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b="W4z+Ot2/"; spf=pass (imf27.hostedemail.com: domain of surenb@google.com designates 209.85.219.180 as permitted sender) smtp.mailfrom=surenb@google.com; dmarc=pass (policy=reject) header.from=google.com X-HE-Tag: 1633575050-295463 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 Wed, Oct 6, 2021 at 7:39 PM Andrew Morton wrote: > > 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! Sure, I will check that and report back. > > > > 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? Sounds good to me. I will post a new version with a separate config if we get over the objections of using numbers instead of strings. Thanks! > > -- > To unsubscribe from this group and stop receiving emails from it, send an email to kernel-team+unsubscribe@android.com. >