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 128A1C433EF for ; Tue, 10 May 2022 20:53:50 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 9A5E66B0071; Tue, 10 May 2022 16:53:49 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 9536B6B0072; Tue, 10 May 2022 16:53:49 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 7F5196B0073; Tue, 10 May 2022 16:53:49 -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 6CA726B0071 for ; Tue, 10 May 2022 16:53:49 -0400 (EDT) Received: from smtpin31.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 410BB21531 for ; Tue, 10 May 2022 20:53:49 +0000 (UTC) X-FDA: 79451034978.31.6A83892 Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.220.28]) by imf16.hostedemail.com (Postfix) with ESMTP id 1318D1800C3 for ; Tue, 10 May 2022 20:53:39 +0000 (UTC) Received: from relay2.suse.de (relay2.suse.de [149.44.160.134]) by smtp-out1.suse.de (Postfix) with ESMTP id 4F7C221BC9; Tue, 10 May 2022 20:53:47 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1652216027; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=oLOHdpuCYzAccJ6ajaHotiOG99qDB43cAS4y17f1Oec=; b=mDJpnWdLo/vamrPVU9LuFUdyYMMMU2py1rUwVE/l5ixKrRbwJ7ncUbVlbywXkEfQ/VKoGI i8yYR6YctJu+b+ooPUYbEvYemkKMlTqe45XeHTn/s5TnCUrMCNNDbvinQGQzFQhem7fjKV I3dTbizO+oqVAStb3iNU29aTuXgFDko= Received: from suse.cz (unknown [10.100.201.86]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by relay2.suse.de (Postfix) with ESMTPS id C98972C141; Tue, 10 May 2022 20:53:46 +0000 (UTC) Date: Tue, 10 May 2022 22:53:43 +0200 From: Michal Hocko To: Suren Baghdasaryan Cc: Andrew Morton , David Rientjes , Matthew Wilcox , 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 Subject: Re: [PATCH 2/3] mm: drop oom code from exit_mmap Message-ID: References: <20220510030014.3842475-1-surenb@google.com> <20220510030014.3842475-2-surenb@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Stat-Signature: 1997kf1qp668u4nihgmz3crss64sceuz X-Rspamd-Server: rspam12 X-Rspamd-Queue-Id: 1318D1800C3 Authentication-Results: imf16.hostedemail.com; dkim=pass header.d=suse.com header.s=susede1 header.b=mDJpnWdL; spf=pass (imf16.hostedemail.com: domain of mhocko@suse.com designates 195.135.220.28 as permitted sender) smtp.mailfrom=mhocko@suse.com; dmarc=pass (policy=quarantine) header.from=suse.com X-Rspam-User: X-HE-Tag: 1652216019-114615 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 10-05-22 09:31:50, Suren Baghdasaryan wrote: > On Tue, May 10, 2022 at 6:06 AM Michal Hocko wrote: > > > > On Mon 09-05-22 20:00:13, Suren Baghdasaryan wrote: > > > With the oom-killer being able to operate on locked pages, exit_mmap > > > does not need to ensure that oom_reap_task_mm is done before it can > > > proceed. Instead it can rely on mmap_lock write lock to prevent > > > oom-killer from operating on the vma tree while it's freeing page > > > tables. exit_mmap can hold mmap_lock read lock when unmapping vmas > > > and then take mmap_lock write lock before freeing page tables. > > > > The changelog is rather light on nasty details which might be good but > > for the sake of our future us let's be more verbose so that we do not > > have to reinvent the prior history each time we are looking into this > > code. I would go with something like this instead: > > " > > The primary reason to invoke the oom reaper from the exit_mmap path used > > to be a prevention of an excessive oom killing if the oom victim exit > > races with the oom reaper (see 212925802454 ("mm: oom: let oom_reap_task > > and exit_mmap run concurrently") for more details. The invocation has > > moved around since then because of the interaction with the munlock > > logic but the underlying reason has remained the same (see 27ae357fa82b > > ("mm, oom: fix concurrent munlock and oom reaper unmap, v3"). > > > > Munlock code is no longer a problem since a213e5cf71cb ("mm/munlock: > > delete munlock_vma_pages_all(), allow oomreap") and there shouldn't be > > any blocking operation before the memory is unmapped by exit_mmap so > > the oom reaper invocation can be dropped. The unmapping part can be done > > with the non-exclusive mmap_sem and the exclusive one is only required > > when page tables are freed. > > > > Remove the oom_reaper from exit_mmap which will make the code easier to > > read. This is really unlikely to make any observable difference although > > some microbenchmarks could benefit from one less branch that needs to be > > evaluated even though it almost never is true. > > " > > Looks great! Thanks for collecting all the history. Will update the description. Please make sure you double check the story. This is mostly my recollection and brief reading through the said commits. I might misremember here and there. -- Michal Hocko SUSE Labs