Received: by 2002:a05:6a10:1d13:0:0:0:0 with SMTP id pp19csp3728008pxb; Mon, 30 Aug 2021 09:15:04 -0700 (PDT) X-Google-Smtp-Source: ABdhPJy+WphJ8oj1M6mZGW8KdAL/x1NPDe1Umc57vZ8+ZukASFm7SfysoWhSgNUF4iG19D21LujC X-Received: by 2002:a17:907:764f:: with SMTP id kj15mr11870692ejc.473.1630340104101; Mon, 30 Aug 2021 09:15:04 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1630340104; cv=none; d=google.com; s=arc-20160816; b=XWxFMjJ0Dk+MdmKpfi6N2GJDEadyV+/EF0LI+MRTusF62LcyvevrT7op0ZkFB6CJAH Nwa5GM3TAy21TrMmqQ5kyx4msQBtxdOsqUXBo4LKUZfB+hEF+GPUBQUp3vnDmBSw6mNl aZmnv/1YEO4OiAexTeC/vDMUtJOTXqvWBXEyuFq23bT1d/5oXdGNtj+vJjUGwXmYE645 X2sTrWl+sY1tqw+zWx3m3fg+A3VxuYy3y4aWX9FdkR6I87uMW2pSnPYkMZQ8RLzfmIiY 4pN7LOOmKPU1JneadAGi+VGb/IplVWosoQkvYxZZkgL3ASbcA9aYmQhgwAQDtmLbGUB7 RjCg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:cc:to:subject :message-id:date:from:in-reply-to:references:mime-version :dkim-signature; bh=1GG6tg8XbUgZaMZCQ5xRATgRnP/jMPvp3jA/MirEbNo=; b=HR9qdJW9Ja8yTo2HFmqgLC0OY3X/D88EXbyr+Mu+krV66Tqo3+d5uGIPl3FBSiup7i kr8IdWcMVq1XtXztUpTc3LtpbOi8msksH2c1XAW3cbgjo7xtqRTulb3zsEKG6WxlK7Qg 9e1O9jalduU8dPvo4EwONoCFmUi3SVJp8Quok4JYulme/DTshDT9wPvw05BXbhhb+ymc Y+CWfs7l6mezJAS4qLRxiVWHWbY2ruIQcJ7/H8mmL5WegPmr3zayzRfMpIDhJMiCvVRw 2aPAjHQxddawJgeuUORIhde2d8ixZ0ZY0o35VrDDoXs+2ckCUKMFBx2+PRohP7ra9Jgz NVJQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=twvcbEdV; 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; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id k13si15670919ejp.411.2021.08.30.09.14.30; Mon, 30 Aug 2021 09:15:04 -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=@google.com header.s=20161025 header.b=twvcbEdV; 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; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S237731AbhH3QNK (ORCPT + 99 others); Mon, 30 Aug 2021 12:13:10 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:45038 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231181AbhH3QNJ (ORCPT ); Mon, 30 Aug 2021 12:13:09 -0400 Received: from mail-yb1-xb2d.google.com (mail-yb1-xb2d.google.com [IPv6:2607:f8b0:4864:20::b2d]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 4686EC061760 for ; Mon, 30 Aug 2021 09:12:16 -0700 (PDT) Received: by mail-yb1-xb2d.google.com with SMTP id k65so29166372yba.13 for ; Mon, 30 Aug 2021 09:12:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=1GG6tg8XbUgZaMZCQ5xRATgRnP/jMPvp3jA/MirEbNo=; b=twvcbEdVEBll9AfkQNe5af0zQd9ziYfYCKCAn9VET2O5NOWONGcLr3SY6j5VijsHIH ApkpmIc6t+2HUtK/lec+2ElqW4bz5E0CDT3wDB1Nue+Mi+6ffiFmM7yZ2qpxSwGNJd+q fmdqxrxlR21OU1mv1NMGzHcu4Gx02yL/Q/h+00WNA3OUghz2WZLfSaoNf0kv1agW/zkQ H+CD+GGnOnvNeqIQVY9MmHW7E8dlOkbXPZfhTo6j7x8ku2/6VAB4q+ZcFyrv3CGvw2WK Y2YR4l69YSC2350Fykt8SGF4QjW7RiDEZVvvjOas0D4IL15nkBVSwyd9vLusrz2TF43D WUpA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=1GG6tg8XbUgZaMZCQ5xRATgRnP/jMPvp3jA/MirEbNo=; b=OSt4aKNE7vTL+xNar6oP0HQWBQ+9FqkT88uYmV44r7yKFU7M/Kf8ITWoykinxLxGYo zXeHR8B5iTaSs6k/Q2BT1mXXzKTelHhSHZq/CtnoMrm6oSiW0ACe9/GPoaTwClPiChkS ccHgt1P0tMfRf/B1JyIQTJTRLMvbLV7lYaZmAnigEhGCqMEf3esBDSTWLpMRlOhmAC4K BiBw72nzt1xd0M+si7bLQ4nJJyEHPRODX4peRDBJC6Ajh0GU6J47dpSQ+hkcSwbf3RlG MmiTqE3h7OrpBb7pl+nm553c3470QaliiqAyBQNcwwR1Ad0n3iDmjdd28AZVj6Fbw53g OPWg== X-Gm-Message-State: AOAM532AJr5IXZuQFhZhmt2HAe1T65w2hyd3hFdYPhtu8ky5l5TNheqo bztK0cWxVfwBPGfhykyVNpBRff3sHyxaVXwJQ4uD2A== X-Received: by 2002:a25:810c:: with SMTP id o12mr26240733ybk.250.1630339935154; Mon, 30 Aug 2021 09:12:15 -0700 (PDT) MIME-Version: 1.0 References: <20210827191858.2037087-1-surenb@google.com> <20210827191858.2037087-4-surenb@google.com> <15537178.k4V9gYNSIy@devpool47> In-Reply-To: <15537178.k4V9gYNSIy@devpool47> From: Suren Baghdasaryan Date: Mon, 30 Aug 2021 09:12:04 -0700 Message-ID: Subject: Re: [PATCH v8 3/3] mm: add anonymous vma name refcounting To: Rolf Eike Beer 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, 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" Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Aug 30, 2021 at 12:03 AM Rolf Eike Beer wrote: > > Am Freitag, 27. August 2021, 21:18:58 CEST schrieb Suren Baghdasaryan: > > While forking a process with high number (64K) of named anonymous vmas = the > > overhead caused by strdup() is noticeable. Experiments with ARM64 Andro= id > > device show up to 40% performance regression when forking a process wit= h > > 64k unpopulated anonymous vmas using the max name lengths vs the same > > process with the same number of anonymous vmas having no name. > > Introduce anon_vma_name refcounted structure to avoid the overhead of > > copying vma names during fork() and when splitting named anonymous vmas= . > > When a vma is duplicated, instead of copying the name we increment the > > refcount of this structure. Multiple vmas can point to the same > > anon_vma_name as long as they increment the refcount. The name member o= f > > anon_vma_name structure is assigned at structure allocation time and is > > never changed. If vma name changes then the refcount of the original > > structure is dropped, a new anon_vma_name structure is allocated > > to hold the new name and the vma pointer is updated to point to the new > > structure. > > With this approach the fork() performance regressions is reduced 3-4x > > times and with usecases using more reasonable number of VMAs (a few > > thousand) the regressions is not measurable. > > > > Signed-off-by: Suren Baghdasaryan > > --- > > include/linux/mm_types.h | 9 ++++++++- > > mm/madvise.c | 42 +++++++++++++++++++++++++++++++++------- > > 2 files changed, 43 insertions(+), 8 deletions(-) > > > > diff --git a/mm/madvise.c b/mm/madvise.c > > index bc029f3fca6a..32ac5dc5ebf3 100644 > > --- a/mm/madvise.c > > +++ b/mm/madvise.c > > @@ -63,6 +63,27 @@ static int madvise_need_mmap_write(int behavior) > > } > > } > > > > +static struct anon_vma_name *anon_vma_name_alloc(const char *name) > > +{ > > + struct anon_vma_name *anon_name; > > + size_t len =3D strlen(name); > > + > > + /* Add 1 for NUL terminator at the end of the anon_name->name */ > > + anon_name =3D kzalloc(sizeof(*anon_name) + len + 1, > > + GFP_KERNEL); > > + kref_init(&anon_name->kref); > > + strcpy(anon_name->name, name); > > + > > + return anon_name; > > +} > > Given that you overwrite anything in that struct anyway this could be red= uced > to kmalloc(), no? And it definitely needs a NULL check. Ack. I'll address both points in the next revision. Thanks! Suren. > > Eike > -- > Rolf Eike Beer, emlix GmbH, http://www.emlix.com > Fon +49 551 30664-0, Fax +49 551 30664-11 > Gothaer Platz 3, 37083 G=C3=B6ttingen, Germany > Sitz der Gesellschaft: G=C3=B6ttingen, Amtsgericht G=C3=B6ttingen HR B 31= 60 > Gesch=C3=A4ftsf=C3=BChrung: Heike Jordan, Dr. Uwe Kracke =E2=80=93 Ust-Id= Nr.: DE 205 198 055 > > emlix - smart embedded open source