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 F093EC433EF for ; Wed, 1 Jun 2022 09:57:17 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 69F5F6B00AB; Wed, 1 Jun 2022 05:57:17 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 64EE68D0003; Wed, 1 Jun 2022 05:57:17 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 565EC6B00AD; Wed, 1 Jun 2022 05:57:17 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 474516B00AB for ; Wed, 1 Jun 2022 05:57:17 -0400 (EDT) Received: from smtpin04.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay11.hostedemail.com (Postfix) with ESMTP id 1786780401 for ; Wed, 1 Jun 2022 09:57:17 +0000 (UTC) X-FDA: 79529214114.04.DAF8537 Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.220.28]) by imf05.hostedemail.com (Postfix) with ESMTP id 1E877100063 for ; Wed, 1 Jun 2022 09:56:41 +0000 (UTC) Received: from relay2.suse.de (relay2.suse.de [149.44.160.134]) by smtp-out1.suse.de (Postfix) with ESMTP id 5868821B7A; Wed, 1 Jun 2022 09:57:15 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1654077435; 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=vlC2BeYATlK9dwXZDZ7Q5yWDx7Zq7aFtfF7/5FtAYVQ=; b=gsPRgzFDarUckMGFTwL08mNBghdCL2BMfNMIGpQq6lwu1FPR3xAvxL94CkQMFilAkAXAnw DKYljjfSwTrB1Bd5tO+0WEz+8Hl6w1xc5saFvomcC8bVTKCBiRDIqfIPzGz8B30DCRuEi9 Y1kfwvktFjNCLcyj3AvK8VK1JJWt46s= 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 DC22E2C141; Wed, 1 Jun 2022 09:57:14 +0000 (UTC) Date: Wed, 1 Jun 2022 11:57:14 +0200 From: Michal Hocko To: Zach O'Keefe Cc: Yang Shi , Matthew Wilcox , Peter Xu , Alex Shi , David Hildenbrand , David Rientjes , Song Liu , Linux MM , Rongwei Wang , Andrea Arcangeli , Axel Rasmussen , Hugh Dickins , "Kirill A. Shutemov" , Minchan Kim , SeongJae Park , Pasha Tatashin Subject: Re: [RFC] mm: MADV_COLLAPSE semantics Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspam-User: Authentication-Results: imf05.hostedemail.com; dkim=pass header.d=suse.com header.s=susede1 header.b=gsPRgzFD; dmarc=pass (policy=quarantine) header.from=suse.com; spf=pass (imf05.hostedemail.com: domain of mhocko@suse.com designates 195.135.220.28 as permitted sender) smtp.mailfrom=mhocko@suse.com X-Rspamd-Server: rspam10 X-Rspamd-Queue-Id: 1E877100063 X-Stat-Signature: 38megy1mwkwd31xwsaebykti4jwrwss5 X-HE-Tag: 1654077401-583260 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 31-05-22 14:36:50, Zach O'Keefe wrote: > Thanks everyone for your time and for the great discussion! > > For the purposes of arriving at a decision, I've tried to outline the > major points + my 2c below as: > > 1. Breaking userland. AFAIK, if permitting MADV_COLLAPSE in "never" > will break real, existing use cases, then linux's policy would > necessitate that we don't do that. Is there a way we can reasonably > determine this? An affirmative answer here makes this decision easy. As pointed in other reply. Never doesn't really imply no THPs. At least shmem doesn't obey that configuration and relies on the mount option instead AFAIR. [...] > 3. Future uses of "never". Do we want to permit a policy where > userspace *entirely* takes over THP allocation, and khugepaged and > at-fault is disabled in the kernel? If yes, then then might as well > permit "never" to allow that now. Personally, though, I can't imagine > wanting to disable faulting-in THPs in places where we know data will > be hot; but respecting "never" does back us into a corner if we ever > go that route. My experience tells me that usecases to take control into the userspace grow rather than shrink. We have people asking for memory reclaim into the userspace and I do not really see reasons why THPs would any different. If we ever really need a global THP kill switch to act on any types of mappings then we would need to add a new knob because changing the existing one would be hard without any regressions. -- Michal Hocko SUSE Labs