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 37E9AC433F5 for ; Tue, 5 Oct 2021 20:43:57 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id DEDDC613D5 for ; Tue, 5 Oct 2021 20:43:56 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org DEDDC613D5 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 50A966B006C; Tue, 5 Oct 2021 16:43:56 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 4BA146B0071; Tue, 5 Oct 2021 16:43:56 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 38163900002; Tue, 5 Oct 2021 16:43:56 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0251.hostedemail.com [216.40.44.251]) by kanga.kvack.org (Postfix) with ESMTP id 2880E6B006C for ; Tue, 5 Oct 2021 16:43:56 -0400 (EDT) Received: from smtpin22.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id C66CE2A00D for ; Tue, 5 Oct 2021 20:43:55 +0000 (UTC) X-FDA: 78663560430.22.5342300 Received: from mail-yb1-f175.google.com (mail-yb1-f175.google.com [209.85.219.175]) by imf09.hostedemail.com (Postfix) with ESMTP id 640113000FE7 for ; Tue, 5 Oct 2021 20:43:55 +0000 (UTC) Received: by mail-yb1-f175.google.com with SMTP id n65so538759ybb.7 for ; Tue, 05 Oct 2021 13:43:55 -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=vqE21VBUis5F7P2tyfYlDOrpKr4yHrwWmAyRNmJWM3s=; b=cLdugDTmr/j2oBSHl6ozvoJ0MUztT02mdFP1wViGsj6Es2vUDXH3ZKf0dgAvBRswBG 4nw7Ii4GeXo/fAzUaTjYOPt6JRHTe8t5Q40Sq/JAY1c2+zHmKNfHZtRuHtrubosUCXjj tNczBaDQ4bhQN0nlecEG5Y8I63K7PrxdUlrLmKmNAxtRSqnjPWgjkdwDPuwh0kUI9rBA m47INqgwtWh1ybXdUOTGhlDh007hgptN9+4uMEw/1iYHGtiI67rUFYFfsxg7a7ih3WLt rVQnsO/wS4iN+N3TONQfPsl0EcuNPmrWUSAnVcHAf52OQoxar1CxZFfZj6r0eJPQ5e1X pD3g== 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=vqE21VBUis5F7P2tyfYlDOrpKr4yHrwWmAyRNmJWM3s=; b=1C+u/fNXJt8KsKCXdiHIgxowuZrB2NUb1+5UyscJD5imKV7mCusZqlpQo2+69J/sQS c698j7IfPYf3ZdAN6j6gRoCNshMBTAFyFvU2S6fRnsFQU489aBQE0zSp2Fm52mk2dMfh OE/D4fXt6OEbzuDYo5HKsFgdpAxsvgEX0kXIa0VfBqZIccGs3W5bPpuv3MClRkXwkNa8 iSsoW4ZFtFV2X/T55uTyQINXU4GVQRPhGVdgOnjqmvT5zewYjsp1vo9CY1CO6u68DHAz L3kDbf5xesQKoaou9fMOk0VIkOdkkps+ZEtJH8Z4LDRULSzh1zfpcZcpopUT1O1TTdBY qDmw== X-Gm-Message-State: AOAM530xGLPEWM/zQO/nhq+PnRd31w3SeMQmBJC6EagYa33zqfjwypjX Tdft4GbZovg0y5mp3aXFu53DVyLd5AORyfhnlYAkqA== X-Google-Smtp-Source: ABdhPJwSm0BVOOZ5kTvRyYIrXx9qnEj/0YszDwLj+4P9EMmNTXKp7nh2cjQfq6luS4PqGmW3SNrlE+Yl4FCV+mWu3MQ= X-Received: by 2002:a25:3:: with SMTP id 3mr24647134yba.418.1633466634369; Tue, 05 Oct 2021 13:43:54 -0700 (PDT) MIME-Version: 1.0 References: <20211001205657.815551-1-surenb@google.com> <20211001205657.815551-3-surenb@google.com> <20211005184211.GA19804@duo.ucw.cz> <20211005200411.GB19804@duo.ucw.cz> In-Reply-To: <20211005200411.GB19804@duo.ucw.cz> From: Suren Baghdasaryan Date: Tue, 5 Oct 2021 13:43:43 -0700 Message-ID: Subject: Re: [PATCH v10 3/3] mm: add anonymous vma name refcounting To: Pavel Machek Cc: Andrew Morton , 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, =?UTF-8?B?Q2hpbndlbiBDaGFuZyAo5by16Yym5paHKQ==?= , 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 , 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-Queue-Id: 640113000FE7 X-Stat-Signature: 6cre7bzz5sgyojnr5u86ij48mh76wh5p Authentication-Results: imf09.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=cLdugDTm; spf=pass (imf09.hostedemail.com: domain of surenb@google.com designates 209.85.219.175 as permitted sender) smtp.mailfrom=surenb@google.com; dmarc=pass (policy=reject) header.from=google.com X-Rspamd-Server: rspam06 X-HE-Tag: 1633466635-230984 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 Tue, Oct 5, 2021 at 1:04 PM Pavel Machek wrote: > > Hi! > > > > On Fri 2021-10-01 13:56:57, Suren Baghdasaryan wrote: > > > > While forking a process with high number (64K) of named anonymous vmas the > > > > overhead caused by strdup() is noticeable. Experiments with ARM64 > > > Android > > > > > > I still believe you should simply use numbers and do the > > > numbers->strings mapping in userspace. We should not need to optimize > > > strdups in kernel... > > > > Here are complications with mapping numbers to strings in the userspace: > > Approach 1: hardcode number->string in some header file and let all > > tools use that mapping. The issue is that whenever that mapping > > changes all the tools that are using it (including 3rd party ones) > > have to be rebuilt. This is not really maintainable since we don't > > control 3rd party tools and even for the ones we control, it will be a > > maintenance issue figuring out which version of the tool used which > > header file. > > 1a) Just put it into a file in /etc... Similar to header file but > easier... > > > Approach 2: have a centralized facility (a process or a DB) > > maintaining number->string mapping. This would require an additional > > request to this facility whenever we want to make a number->string > > conversion. Moreover, when we want to name a VMA, we would have to > > I see it complicates userspace. But that's better than complicating > kernel, and I don't know what limits on strings you plan, but > considering you'll be outputing the strings in /proc... someone is > going to get confused with parsing. I'm not a fan of complicating kernel but the proposed approach seems simple enough to me. Again this is subjective, so I can't really have a good argument here. Maybe, as Andrew suggested, I should keep it under a separate config so that whoever does not care about this feature pays no price for it? On the topic of confusing the parsers, if the parser is written so that it can't ignore new [anon:...] entry then it does not matter whether we use strings or numbers, it will get confused either way. Again, if we are concerned about confusing existing parsers I think having a separate config option set to 'n' would help. This would prevent some userspace process from naming an anonymous VMA and causing parser confusion. OTOH on systems where parsers can handle anon VMA names (Android) we will set that config and use the feature. Would that address your concerns? > > Pavel > -- > http://www.livejournal.com/~pavelmachek