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 9050BC433FE for ; Wed, 9 Feb 2022 15:36:03 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id CF2556B0074; Wed, 9 Feb 2022 10:36:02 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id CA2286B0075; Wed, 9 Feb 2022 10:36:02 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B8FF96B0078; Wed, 9 Feb 2022 10:36:02 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0197.hostedemail.com [216.40.44.197]) by kanga.kvack.org (Postfix) with ESMTP id AAFD26B0074 for ; Wed, 9 Feb 2022 10:36:02 -0500 (EST) Received: from smtpin21.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id 5C6C1181D7ED5 for ; Wed, 9 Feb 2022 15:36:02 +0000 (UTC) X-FDA: 79123642164.21.395122C Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.220.28]) by imf31.hostedemail.com (Postfix) with ESMTP id DFE6320006 for ; Wed, 9 Feb 2022 15:36:01 +0000 (UTC) Received: from relay2.suse.de (relay2.suse.de [149.44.160.134]) by smtp-out1.suse.de (Postfix) with ESMTP id 9F84821106; Wed, 9 Feb 2022 15:36:00 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1644420960; 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=fiB/RLA6+TRPqiQcsJO/7jhpKwwOHhChnXu8OxtZJF8=; b=Eg39W1KhWOahMF4A1WT7hIsLEiwE3gTmUaPCXZ5KqFrqA9wLmpSk/tyKevPPhJi2l7t7Qh PApTRciEYxRKIqeSk0m4ZA4Hz1NNH+G0Ai83QbG1P/lrvUVagPrRvO5glCYzsj321l89f4 oSh5zJHH4LC/yD0pNAPM2pZ5wNsF8mQ= 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 430AEA3B84; Wed, 9 Feb 2022 15:36:00 +0000 (UTC) Date: Wed, 9 Feb 2022 16:35:59 +0100 From: Michal Hocko To: Hugh Dickins Cc: Andrew Morton , Vlastimil Babka , "Kirill A. Shutemov" , Matthew Wilcox , David Hildenbrand , Alistair Popple , Johannes Weiner , Rik van Riel , Suren Baghdasaryan , Yu Zhao , Greg Thelen , Shakeel Butt , linux-kernel@vger.kernel.org, linux-mm@kvack.org Subject: Re: [PATCH 00/13] mm/munlock: rework of mlock+munlock page handling Message-ID: References: <8e4356d-9622-a7f0-b2c-f116b5f2efea@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8e4356d-9622-a7f0-b2c-f116b5f2efea@google.com> X-Stat-Signature: g1iy5qtg1od5bneqzfu1zpkbwfzk4wt9 X-Rspam-User: Authentication-Results: imf31.hostedemail.com; dkim=pass header.d=suse.com header.s=susede1 header.b=Eg39W1Kh; dmarc=pass (policy=quarantine) header.from=suse.com; spf=pass (imf31.hostedemail.com: domain of mhocko@suse.com designates 195.135.220.28 as permitted sender) smtp.mailfrom=mhocko@suse.com X-Rspamd-Server: rspam08 X-Rspamd-Queue-Id: DFE6320006 X-HE-Tag: 1644420961-212607 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 Sun 06-02-22 13:27:41, Hugh Dickins wrote: > I wondered whether to post this munlocking rework in > https://lore.kernel.org/linux-mm/35c340a6-96f-28a0-2b7b-2f9fbddc01f@google.com/ > > There the discussion was OOM reaping, but the main reason for the rework > has been catastrophic contention on i_mmap_rwsem when exiting from > multiply mlocked files; and frustration with how contorted munlocking is. yeah, I do not think that too many care about oom_reaper stumbling over vast portions of the mlocked memory problem. So far I have seen only LTP oom02 hitting this and that one does mlockall and intentionally hits OOM. So far I haven't seen any actual workload hiting something similar. But hey, if we get a better and easier to maintain mlock code then the oom_reaper will surely add to a huge thanks. > Here it is based on 5.17-rc2, applies also to -rc3, almost cleanly to > mmotm 2022-02-03-21-58 (needs two easy fixups in mm/huge_memory.c); but > likely to conflict (I hope not fundamentally) with several concurrent > large patchsets. > > tl;dr > mm/mlock.c | 634 +++++++++++++++----------------------- > 23 files changed, 510 insertions(+), 779 deletions(-) This is really impressive! > In my own opinion, this is ready to go in: that whatever its defects, > it's a big practical improvement over what's presently there. Others > may differ; and it may be too much to arrive at a quick opinion on. > My hope is that it will strike a chord with some who have laboured in > this area in the past: I'll be short of time to do much more with it, > so maybe someone else could take over if necessary. > > At present there's no update to Documentation/vm/unevictable-lru.rst: > that always needs a different mindset, can follow later, please refer > to commit messages for now. Yes, that would help for sure. So far I have only managed to read through the series and trying to put all the pieces together (so far I have given up on the THP part) and my undestanding is far from complete. But I have to say I like the general approach and overall simplification. The only thing that is not entirely clear to me at the moment is why you have chosen to ignore already mapped LOCKONFAULT pages. They will eventually get sorted out during the reclaim/migration but this can backfire if too many pages have been pre-faulted before LOCKONFAULT call. Maybe not an interesting case in the first place but I am still wondering why you have chosen that way. I will be off next couple of days and plan to revisit this afterwards (should time allow). Anyway thanks a lot Hugh! -- Michal Hocko SUSE Labs