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 9AA23C433FE for ; Tue, 2 Nov 2021 15:14:57 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 2E19A60F5A for ; Tue, 2 Nov 2021 15:14:57 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 2E19A60F5A 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 871E5940009; Tue, 2 Nov 2021 11:14:56 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 820F66B0072; Tue, 2 Nov 2021 11:14:56 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 73695940009; Tue, 2 Nov 2021 11:14:56 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0081.hostedemail.com [216.40.44.81]) by kanga.kvack.org (Postfix) with ESMTP id 61D086B0071 for ; Tue, 2 Nov 2021 11:14:56 -0400 (EDT) Received: from smtpin04.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id 237D01828ECD3 for ; Tue, 2 Nov 2021 15:14:56 +0000 (UTC) X-FDA: 78764337792.04.A7DAAE0 Received: from mail-yb1-f169.google.com (mail-yb1-f169.google.com [209.85.219.169]) by imf30.hostedemail.com (Postfix) with ESMTP id 05127E0016A1 for ; Tue, 2 Nov 2021 15:14:40 +0000 (UTC) Received: by mail-yb1-f169.google.com with SMTP id s3so20606883ybs.9 for ; Tue, 02 Nov 2021 08:14: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=m4vo3xOow7zioCDniOqo/cUmPTsQ9k5oLRBoc2H5RmM=; b=LjddqU8TuEc2mSGQVv8Shw6Rr8F04MBGWv+W9yGEUEesBAdukLgf4ydPLMDaao9Wdw 9WLQvTXkckHoyRv6v9GtcQoSUqzNA61qJKqXNqcM6Dnek77lhQqK/epy8W9dn2XJTY0D 5Hu193h2Bd0tO0VjKZX99CKIYedxlVnhR4JCkYCE/HxlIFSA2W+wXQ+pVuYUCi2eI8Dz Wfc8Fj+9itDanLTLbQ94LQqSz2tUOXmnTPsWjOsTR54diV0sM/fHxQ2UILjdC/hLJtJL Mg/UJHcPBF/D9ZufOMQ2XQlFAzttQ/jqQSJ9gzipUDab72pOLdanRYCcxzwlhw7og6jV awxg== 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=m4vo3xOow7zioCDniOqo/cUmPTsQ9k5oLRBoc2H5RmM=; b=P2OKNw/K5K0loYkRkApbSij4xlMYqTFZp26LDoP1LdXMQ8zB8L3W+4SKNgKBl1nq4E NVVObHpYEwiNiGDHGFMBBteI1zK9y/sEVX/ekYm4w5LrlvXm3IeU4HvjuHLZZZn28Qqb uZ58DgW9QB1SKxO1Xp3bGfZFYXmG3+aFHjoHyPsXMwiYIlb5MNpM7UZdNOQfv+KbUFYU 9IpiVUqUM48oMg42toZEDHT8Z2KSHRIj3IwK1eUb7bUJPJKYawJrBsgkEQQ9cqvUKzu0 1VEUc6gXj2//2LMkDKL/dZ8nJ3uHciI7ekbXqX9vdIzQ7HkrGKOmPiVneTfQ0uv56ipd nLNQ== X-Gm-Message-State: AOAM532ih4kgqbbOT1/UJ8chaPIxL/rA3rLT/Qlak4PWI6qIVyX4Q7RB bMpdlrqbq4Q8d5D/MI35nK/+TvwaQ5oo7C1BatHMfQ== X-Google-Smtp-Source: ABdhPJzVNIQAwK+DaQmN14pKDqKRyuYzpi/QTvph4WYwByoDr2ZVNR43H0trqcjKVtUtTg2UFfwMO19+eG3dj3An+7g= X-Received: by 2002:a25:2f58:: with SMTP id v85mr33607068ybv.487.1635866094771; Tue, 02 Nov 2021 08:14:54 -0700 (PDT) MIME-Version: 1.0 References: <20211022014658.263508-1-surenb@google.com> In-Reply-To: From: Suren Baghdasaryan Date: Tue, 2 Nov 2021 08:14:43 -0700 Message-ID: Subject: Re: [PATCH 1/1] mm: prevent a race between process_mrelease and exit_mmap To: Michal Hocko Cc: Andrew Morton , David Rientjes , Matthew Wilcox , Johannes Weiner , Roman Gushchin , Rik van Riel , Minchan Kim , Christian Brauner , Christoph Hellwig , Oleg Nesterov , David Hildenbrand , Jann Horn , Shakeel Butt , Andy Lutomirski , Christian Brauner , Florian Weimer , Jan Engelhardt , Linux API , linux-mm , LKML , kernel-team , "Kirill A. Shutemov" , Andrea Arcangeli Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 05127E0016A1 X-Stat-Signature: ym6rfynsxe5cnnu6ynifixptcsaisf4j Authentication-Results: imf30.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=LjddqU8T; spf=pass (imf30.hostedemail.com: domain of surenb@google.com designates 209.85.219.169 as permitted sender) smtp.mailfrom=surenb@google.com; dmarc=pass (policy=reject) header.from=google.com X-Rspamd-Server: rspam02 X-HE-Tag: 1635866080-78178 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, Nov 2, 2021 at 12:58 AM Michal Hocko wrote: > > On Mon 01-11-21 08:44:58, Suren Baghdasaryan wrote: > [...] > > I'm with you on this one, that's why I wanted to measure the price we > > would pay. Below are the test results: > > > > Test: https://lore.kernel.org/all/20170725142626.GJ26723@dhcp22.suse.cz/ > > Compiled: gcc -O2 -static test.c -o test > > Test machine: 128 core / 256 thread 2x AMD EPYC 7B12 64-Core Processor > > (family 17h) > > > > baseline (Linus master, f31531e55495ca3746fb895ffdf73586be8259fa) > > p50 (median) 87412 > > p95 168210 > > p99 190058 > > average 97843.8 > > stdev 29.85% > > > > unconditional mmap_write_lock in exit_mmap (last column is the change > > from the baseline) > > p50 (median) 88312 +1.03% > > p95 170797 +1.54% > > p99 191813 +0.92% > > average 97659.5 -0.19% > > stdev 32.41% > > > > unconditional mmap_write_lock in exit_mmap + Matthew's patch (last > > column is the change from the baseline) > > p50 (median) 88807 +1.60% > > p95 167783 -0.25% > > p99 187853 -1.16% > > average 97491.4 -0.36% > > stdev 30.61% > > > > stdev is quite high in all cases, so the test is very noisy. > > The impact seems quite low IMHO. WDYT? > > Results being very noisy is what I recall as well. Thanks! I believe, despite the noise, the percentiles show that overall we do not noticeably regress the exit path by taking mmap_lock unconditionally. If there are no objections, I would like to post a patchset which implements unconditional locking in exit_mmap() and process_madvise() calling __oom_reap_task_mm() under protection of read mmap_lock. Thanks! > -- > Michal Hocko > SUSE Labs