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 57E01C433EF for ; Wed, 27 Oct 2021 18:01:54 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id F01B8610A0 for ; Wed, 27 Oct 2021 18:01:53 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org F01B8610A0 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 7B1946B0071; Wed, 27 Oct 2021 14:01:53 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 738CB80007; Wed, 27 Oct 2021 14:01:53 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 5D9EC940007; Wed, 27 Oct 2021 14:01:53 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0052.hostedemail.com [216.40.44.52]) by kanga.kvack.org (Postfix) with ESMTP id 383786B0071 for ; Wed, 27 Oct 2021 14:01:53 -0400 (EDT) Received: from smtpin35.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id B204F180442FB for ; Wed, 27 Oct 2021 18:01:52 +0000 (UTC) X-FDA: 78742985664.35.914B95B Received: from mail-yb1-f175.google.com (mail-yb1-f175.google.com [209.85.219.175]) by imf07.hostedemail.com (Postfix) with ESMTP id 2CC4B10004F5 for ; Wed, 27 Oct 2021 18:00:52 +0000 (UTC) Received: by mail-yb1-f175.google.com with SMTP id m63so8408904ybf.7 for ; Wed, 27 Oct 2021 11:00:51 -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=clXqNUS4aH+lp7CvysKQZD0qyG4h3WcOXjDUltwQb6U=; b=spy08q38upaQmQzNFn22bVmpGqRkZpMLppZP19FX208LVS7bKM4p1WeH7C/kIK3w8B mQjpjthV9ux54iJ7m72QuqrZ2q7MKOh9YIrboIp9GiJltpaPe7MBwGGrf10K9a/9DmUE A3akdddQnK5CYb/RP1LTJfQe5TEW6vgiDIMts94pHTBPOcibp/cS97WEFH6/ohUaz6ss YICJ8xcA8zSlf01Do5w8utuY32NLGysFmBGVLnBVxxenTlWqaIG6YkyD0Aa72ZpGcJX9 bRYc0omYodEAYDs8ROqb9T8mg+BmVfQBJUXQmV6cg/vxpBr6fmbtKjoIExWK+oJlhc8t sn0A== 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=clXqNUS4aH+lp7CvysKQZD0qyG4h3WcOXjDUltwQb6U=; b=tZjRp5mCAZa08IF0HK17LF0P10r5P3y13ibLuyg80o8QlsEVRELD1//cnAQt7VrD+o fVDDQ3MMnL/z8hTCv1ZojPHVLZFKRqNGuXYzd7LLL6JiaCd52JhUKYac5Aw3NYeu6qGX ZprsIc/baAn/rI3lXwFrjTlAQ78S+H56aWYDcoX2kWgYdGrH2wvQZ6n5nj0a2wSNDbRz NiriWFaXtJbC7I4+0iWEjvHOktwD4H/nLctMwZjzrPO6GcKpm2tNFJHWwWna7UzyhEPL +u7EZhwp+FNfeb4b1a0EJt8pfhvbs483j5wD2tBO5BOX2Sa+0nAfXPrz4/4TyeUGM42q 000w== X-Gm-Message-State: AOAM533Bm2vmR2laQHMcDNkngA/2P2Vj0lKu4b4VOojM3CM4fQimuQkh KCZH9oOgFvpT1KcKmIZr/sxvoQR102R9ldnfAS4kHQ== X-Google-Smtp-Source: ABdhPJw+b4ieaS+XkelygwszTNfA8iUxOPZ3IyD0AyktmJLzezrD+qqN5C7+sdyzIu3rekl+DE5Hn023AAKjGGWtu0w= X-Received: by 2002:a25:2f48:: with SMTP id v69mr11873590ybv.487.1635357649502; Wed, 27 Oct 2021 11:00:49 -0700 (PDT) MIME-Version: 1.0 References: <20211022014658.263508-1-surenb@google.com> In-Reply-To: From: Suren Baghdasaryan Date: Wed, 27 Oct 2021 11:00:38 -0700 Message-ID: Subject: Re: [PATCH 1/1] mm: prevent a race between process_mrelease and exit_mmap To: Matthew Wilcox Cc: "Liam R. Howlett" , Michal Hocko , Andrew Morton , David Rientjes , 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: 2CC4B10004F5 Authentication-Results: imf07.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=spy08q38; spf=pass (imf07.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-Stat-Signature: 9hw9ueujpkh5syza87kxpxxa6kmdd4ed X-Rspamd-Server: rspam06 X-HE-Tag: 1635357652-700443 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 Wed, Oct 27, 2021 at 10:52 AM Matthew Wilcox wrote: > > On Wed, Oct 27, 2021 at 10:42:29AM -0700, Suren Baghdasaryan wrote: > > On Wed, Oct 27, 2021 at 10:35 AM Matthew Wilcox wrote: > > > > > > On Wed, Oct 27, 2021 at 09:08:21AM -0700, Suren Baghdasaryan wrote: > > > > Unconditional mmap_write_lock around free_pgtables in exit_mmap seems > > > > to me the most semantically correct way forward and the pushback is on > > > > the basis of regressing performance of the exit path. I would like to > > > > measure that regression to confirm this. I don't have access to a big > > > > machine but will ask someone in another Google team to try the test > > > > Michal wrote here > > > > https://lore.kernel.org/all/20170725142626.GJ26723@dhcp22.suse.cz/ on > > > > a server with and without a custom patch. > > > > > > Sorry to hijack this, but could you ask that team to also test this > > > patch? I think there's probably a good-sized win here, but I have no > > > profiles to share at this point. I've only done light testing, and > > > it may have bugs. > > > > > > NB: I only did the exit() path here. fork() conversion is left as an > > > exercise for the reader^W^W Liam. > > > > To clarify, this patch does not change the mmap_write_lock portion of > > exit_mmap. Do you want to test it in isolation or with the locking > > changes in exit_mmap I mentioned? > > Correct, it does not. I think it's interesting to test it in isolation, > but if you want to test it in in combination, that could also be > interesting (see if we regain some of the expected performance loss). > I just don't have a NUMA box of my own to test on, so I'm hoping to > exploit your test infrastructure ;-) > > By the way, my vmavec patch should also be helpful on small systems > like phones ... ;-) Sounds good. I'll try to queue up the patches so that it's easy to test them both in isolation and together.