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 kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 5CE18C433EF for ; Thu, 2 Jun 2022 13:40:21 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id CFC086B0071; Thu, 2 Jun 2022 09:40:20 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id CAB3B6B0073; Thu, 2 Jun 2022 09:40:20 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B49CC6B0074; Thu, 2 Jun 2022 09:40:20 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id A68D06B0071 for ; Thu, 2 Jun 2022 09:40:20 -0400 (EDT) Received: from smtpin21.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 6E0E335484 for ; Thu, 2 Jun 2022 13:40:20 +0000 (UTC) X-FDA: 79533405000.21.5480A8A Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf26.hostedemail.com (Postfix) with ESMTP id EBC8C14005A for ; Thu, 2 Jun 2022 13:40:14 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=cYfEvCQT+uciRQa6krW9NS+mCqa1kfyLmC48zuNRnoY=; b=Xan9o4ckQ1TkMX1sXOlS09b4fc YlC+sT3AQvMozlpPmNIgq9TukbWZrGOdiJ1mYFW8t/I7pLpOJiK/S+l7G/GIyFCL67jw05ciLA579 G2HfufNdHsQoC3UydGUucTfoPlPpSsMB9tBaIhvBkg1HKPDD/+qQYWZ9Krrpu8D1qkyeJOpgFmpZL XF3iEs0T686Y1oGblFPmjG3PGompJN08kWUZKgmVwFE0Lfb2cpiTN9YEIt6l9MzTWhQKoGT/brBRg dTMgnGYiXxBubIRXodZDq43TFhSJNNwtlQAAhtT9f7AdISeyg1PBsh71MGnec5RmEvEno0TDkVLl7 hTrr7yoQ==; Received: from willy by casper.infradead.org with local (Exim 4.94.2 #2 (Red Hat Linux)) id 1nwl3E-007Avw-95; Thu, 02 Jun 2022 13:39:48 +0000 Date: Thu, 2 Jun 2022 14:39:48 +0100 From: Matthew Wilcox To: Suren Baghdasaryan Cc: Andrew Morton , Michal Hocko , David Rientjes , Johannes Weiner , Roman Gushchin , Minchan Kim , "Kirill A. Shutemov" , Andrea Arcangeli , Christian Brauner , Christoph Hellwig , Oleg Nesterov , David Hildenbrand , Jann Horn , Shakeel Butt , Peter Xu , John Hubbard , shuah@kernel.org, LKML , linux-mm , linux-kselftest@vger.kernel.org, kernel-team , Liam Howlett Subject: Re: [PATCH RESEND v2 1/2] mm: drop oom code from exit_mmap Message-ID: References: <20220531223100.510392-1-surenb@google.com> <20220601143638.9e78c470d2c980053cc8059a@linux-foundation.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Stat-Signature: eb9y79j8q9q73895mgk1m3enhqmnheer X-Rspam-User: Authentication-Results: imf26.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=Xan9o4ck; spf=none (imf26.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org; dmarc=none X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: EBC8C14005A X-HE-Tag: 1654177214-255852 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, Jun 01, 2022 at 02:47:41PM -0700, Suren Baghdasaryan wrote: > > Unclear why this patch fiddles with the mm_struct locking in this > > fashion - changelogging that would have been helpful. > > Yeah, I should have clarified this in the description. Everything up > to unmap_vmas() can be done under mmap_read_lock and that way > oom-reaper and process_mrelease can do the unmapping in parallel with > exit_mmap. That's the reason we take mmap_read_lock, unmap the vmas, > mark the mm with MMF_OOM_SKIP and take the mmap_write_lock to execute > free_pgtables. I think maple trees do not change that except there is > no mm->mmap anymore, so the line at the end of exit_mmap where we > reset mm->mmap to NULL can be removed (I show that line below). I don't understand why we _want_ unmapping to proceed in parallel? Is it so urgent to unmap these page tables that we need two processes doing it at the same time? And doesn't that just change the contention from visible (contention on a lock) to invisible (contention on cachelines)?