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 4A203C4332F for ; Wed, 6 Oct 2021 08:28:04 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 2FBD7610FB for ; Wed, 6 Oct 2021 08:28:04 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S237647AbhJFI3x (ORCPT ); Wed, 6 Oct 2021 04:29:53 -0400 Received: from smtp-out1.suse.de ([195.135.220.28]:45894 "EHLO smtp-out1.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231145AbhJFI3u (ORCPT ); Wed, 6 Oct 2021 04:29:50 -0400 Received: from relay2.suse.de (relay2.suse.de [149.44.160.134]) by smtp-out1.suse.de (Postfix) with ESMTP id 44FB4224C1; Wed, 6 Oct 2021 08:27:57 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1633508877; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=E/6HtAb0SdSz7BkiP3vnxEjZN89ZpTwbmcif+6QXT1Q=; b=nYikioOxXuZDyMI2sYHhQLYKpRyOPJyfYTgw8c4byiW5NZrEE2NXTV2v+Bmy/HAV0eGbWh Xb0WUCm2D+Nwnl/kBGP8MWT+q7SF+YsECSF9OALaQJASEGMuTqOPL8jKW/pXEXlSd+uZ94 bWI8FW7y+23ZFbOJnkXy9RhICCpPsIg= Received: from suse.cz (unknown [10.100.201.86]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by relay2.suse.de (Postfix) with ESMTPS id 38B8DA3B8A; Wed, 6 Oct 2021 08:27:55 +0000 (UTC) Date: Wed, 6 Oct 2021 10:27:54 +0200 From: Michal Hocko To: John Hubbard Cc: Suren Baghdasaryan , Pavel Machek , 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, Chinwen Chang =?utf-8?B?KOW8temMpuaWhyk=?= , 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@oracle.com, 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, Rasmus Villemoes , LKML , linux-fsdevel@vger.kernel.org, linux-doc@vger.kernel.org, linux-mm , kernel-team Subject: Re: [PATCH v10 3/3] mm: add anonymous vma name refcounting Message-ID: References: <20211001205657.815551-1-surenb@google.com> <20211001205657.815551-3-surenb@google.com> <20211005184211.GA19804@duo.ucw.cz> <20211005200411.GB19804@duo.ucw.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue 05-10-21 23:57:36, John Hubbard wrote: [...] > 1) Yes, just leave the strings in the kernel, that's simple and > it works, and the alternatives don't really help your case nearly > enough. I do not have a strong opinion. Strings are easier to use but they are more involved and the necessity of kref approach just underlines that. There are going to be new allocations and that always can lead to surprising side effects. These are small (80B at maximum) so the overall footpring shouldn't all that large by default but it can grow quite large with a very high max_map_count. There are workloads which really require the default to be set high (e.g. heavy mremap users). So if anything all those should be __GFP_ACCOUNT and memcg accounted. I do agree that numbers are just much more simpler from accounting, performance and implementation POV. > The kernel changes at a different rate than distros and > user space, and keeping number->string mappings updated and correct > is just basically hopeless. I am not sure I follow here. This all looks like a userspace policy. No matter what kind of id you use. It is userspace to set and consume those ids. Why is it different to use strings from numbers. All parties have to agree in a naming/numbering convention anyway. Those might differ on Android or other userspaces. What am I missing? > And you've beaten down the perf problems with kref, so it's fine. > > 2) At the same time, this feature is Just Not Needed! ...usually. > So the config option seems absolutely appropriate. This is not really an answer. Most users are using a distro kernel so this would need to be enabled in those configs just in case. -- Michal Hocko SUSE Labs