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 D7C62C433FE for ; Mon, 1 Nov 2021 15:45:18 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 7069E61058 for ; Mon, 1 Nov 2021 15:45:18 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 7069E61058 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 AD73D94001C; Mon, 1 Nov 2021 11:45:17 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id A86D394000F; Mon, 1 Nov 2021 11:45:17 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 9287A94001C; Mon, 1 Nov 2021 11:45:17 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0110.hostedemail.com [216.40.44.110]) by kanga.kvack.org (Postfix) with ESMTP id 7F7E394000F for ; Mon, 1 Nov 2021 11:45:17 -0400 (EDT) Received: from smtpin03.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id 380231840B3B6 for ; Mon, 1 Nov 2021 15:45:17 +0000 (UTC) X-FDA: 78760785474.03.E31F714 Received: from mail-yb1-f179.google.com (mail-yb1-f179.google.com [209.85.219.179]) by imf31.hostedemail.com (Postfix) with ESMTP id 418001044829 for ; Mon, 1 Nov 2021 15:45:12 +0000 (UTC) Received: by mail-yb1-f179.google.com with SMTP id a129so32548032yba.10 for ; Mon, 01 Nov 2021 08:45:16 -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=ZolZYi1Z2qAq+BdRoisdf3B03ivIqQVmB8Zw09nzu/A=; b=QO56lhV56aUSXb5cp5vwYlnjJuQqx0rZxic/SzMXvbF1nWztHVKxodvJXVy1AoROHk Cl3ep7m2UwaJ39Y/IGbfUJ2gor11hX8Ilimaw+ly07DUufwbpsjfOE0K9eD+wGMUU7mJ BXfB52ihVoEKPyX8MuJrHcP6tdepZkqFE9yQY9WAY8t3j5oRhJCWfRVxFF0qRVAAe9gI c/2ht1FMS+3Be+6eun16zvnn5nBp50PwzTMkvfs1yOGGs2QbT9tegBC/KR/rmLis0XMI NJHEuMO9SSgfacSyYAz860rC+vlmp/hG4MkOXligVzYPPz6yYxIarv9WgjmZf52HqW/W zLzw== 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=ZolZYi1Z2qAq+BdRoisdf3B03ivIqQVmB8Zw09nzu/A=; b=MHVcOZ8ys0Q2mOfJ6szInv6OqvFrLrvuV/HNh0cFMFdgtwgG7QjiZJ32YG98hRjsV5 A/sTm4YzSMfA0Qdq7xvXKpvaqhR2GG8sqd+Y28s1YdyItCeZ9dJ+h7ocHuTQMHVrb/Xf sx9VZ2u3tmL0jAY/ZFtTd1uWK5MWJL5N9prtG3RDoIMxVhOOxuAcXNafUxp7v1tOZIJM XgOxZK3WkYKAEWZVnBWDEIHEvk5AfXEjYtqRnSN6Es/SKBKpsJmsAwt7RtuweqjdboUm 4llpNSW3+Zb800xiBPJLkp+FpQPbvPtpvLkpC9SVAUwfgNIxqsGVGBV6wzIHpgDkI/L3 X5Dg== X-Gm-Message-State: AOAM531jQUEVZtBa6x6N4NBpAXxARMqKiTC29kTTjzZj907x8cjfij4b xqPWyXDve93H9fTDSUwXcm3YUgHtEQV3wi9lSXRSJQ== X-Google-Smtp-Source: ABdhPJy7Y2xviMqGlKunRSE1bYGIzhMjrRr9qPYvk8vGlzZTFvMRzKzHep+EnxjFd74GwRZBeyfOPrds+hz4ErGZTUE= X-Received: by 2002:a25:ae12:: with SMTP id a18mr10895832ybj.412.1635781510066; Mon, 01 Nov 2021 08:45:10 -0700 (PDT) MIME-Version: 1.0 References: <20211022014658.263508-1-surenb@google.com> In-Reply-To: From: Suren Baghdasaryan Date: Mon, 1 Nov 2021 08:44:58 -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-Server: rspam04 X-Rspamd-Queue-Id: 418001044829 Authentication-Results: imf31.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=QO56lhV5; spf=pass (imf31.hostedemail.com: domain of surenb@google.com designates 209.85.219.179 as permitted sender) smtp.mailfrom=surenb@google.com; dmarc=pass (policy=reject) header.from=google.com X-Stat-Signature: 5853do5fxcquhy61dys7p4nnufi5ocia X-HE-Tag: 1635781512-99222 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 Mon, Nov 1, 2021 at 1:37 AM Michal Hocko wrote: > > On Fri 29-10-21 09:07:39, Suren Baghdasaryan wrote: > > On Fri, Oct 29, 2021 at 6:03 AM Michal Hocko wrote: > [...] > > > Well, I still do not see why that is a problem. This syscall is meant to > > > release the address space not to do it fast. > > > > It's the same problem for a userspace memory reaper as for the > > oom-reaper. The goal is to release the memory of the victim and to > > quickly move on to the next one if needed. > > The purpose of the oom_reaper is to _guarantee_ a forward progress. It > doesn't have to be quick or optimized for speed. Fair enough. Then the same guarantees should apply to userspace memory reapers. I think you clarified that well in your replies in https://lore.kernel.org/all/20170725154514.GN26723@dhcp22.suse.cz: Because there is no _guarantee_ that the final __mmput will release the memory in finite time. And we cannot guarantee that longterm. ... __mmput calls into exit_aio and that can wait for completion and there is no way to guarantee this will finish in finite time. > > [...] > > > > Btw. the above code will not really tell you much on a larger machine > > > unless you manage to trigger mmap_sem contection. Otherwise you are > > > measuring the mmap_sem writelock fast path and that should be really > > > within a noise comparing to the whole address space destruction time. If > > > that is not the case then we have a real problem with the locking... > > > > My understanding of that discussion is that the concern was that even > > taking uncontended mmap_sem writelock would regress the exit path. > > That was what I wanted to confirm. Am I misreading it? > > No, your reading match my recollection. I just think that code > robustness in exchange of a rw semaphore write lock fast path is a > reasonable price to pay even if that has some effect on micro > benchmarks. 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? > -- > Michal Hocko > SUSE Labs