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 C0072C433F5 for ; Fri, 27 May 2022 08:57:03 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 4B83F8D0003; Fri, 27 May 2022 04:57:03 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 467998D0001; Fri, 27 May 2022 04:57:03 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 32B278D0003; Fri, 27 May 2022 04:57:03 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 25AB78D0001 for ; Fri, 27 May 2022 04:57:03 -0400 (EDT) Received: from smtpin29.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id F245B2125B for ; Fri, 27 May 2022 08:57:02 +0000 (UTC) X-FDA: 79510918284.29.3EBF389 Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.220.29]) by imf29.hostedemail.com (Postfix) with ESMTP id DC7BA12003E for ; Fri, 27 May 2022 08:56:50 +0000 (UTC) Received: from relay2.suse.de (relay2.suse.de [149.44.160.134]) by smtp-out2.suse.de (Postfix) with ESMTP id 446901F93D; Fri, 27 May 2022 08:57:01 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1653641821; 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=Y4L9VTq0LqM03ekBg6WiSH6V03Bsv3UFXlQ2xetvi7s=; b=rTK5htaZBKvFGlGh3EyMyPGN1br3x3zn/5vGZEPMvYEBxDqRyNdMBT2xM24Gd/xB70YWP7 L12VfRPzQ2zwiE81PQZ/bcOe2QdGls7Bty+WBevVn/xCyZajbl9vGlu4F0ipAaY9hDvOAW Coi2stKsNzylipKQx/CKIMPKY5QnllE= 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 C46872C141; Fri, 27 May 2022 08:56:59 +0000 (UTC) Date: Fri, 27 May 2022 10:56:59 +0200 From: Michal Hocko To: Matthew Wilcox Cc: Zach O'Keefe , Alex Shi , David Hildenbrand , David Rientjes , Peter Xu , Song Liu , Yang Shi , linux-mm@kvack.org, rongwei.wang@linux.alibaba.com, 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-Rspamd-Queue-Id: DC7BA12003E X-Rspam-User: Authentication-Results: imf29.hostedemail.com; dkim=pass header.d=suse.com header.s=susede1 header.b=rTK5htaZ; spf=pass (imf29.hostedemail.com: domain of mhocko@suse.com designates 195.135.220.29 as permitted sender) smtp.mailfrom=mhocko@suse.com; dmarc=pass (policy=quarantine) header.from=suse.com X-Stat-Signature: bbrsfyrn5dnhkt6t1sdkewgjt7fmad34 X-Rspamd-Server: rspam05 X-HE-Tag: 1653641810-684868 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 Thu 26-05-22 19:30:20, Matthew Wilcox wrote: > On Wed, May 25, 2022 at 10:24:55AM +0200, Michal Hocko wrote: > > I am not so sure about the global "never" policy, though. The global > > policy controls _kernel_ driven THPs. As the request to collapse memory > > comes from the userspace I do not think it should be limited by the > > kernel policy. I also think it can be beneficial to implement userspace > > based THP policies and exclude any kernel interference and that could be > > achieved by global kernel "never" policy and implement the whole > > functionality by process_madvise. > > I'd prefer to see "never" mean "Don't run khugepaged" rather than "Do > not create THPs". If the app explicitly asks for a THP, I think it > should get one, regardless of the sysadmin's will. > > Death to tunables. Can we just delete > /sys/kernel/mm/transparent_hugepage/shmem_enabled entirely? I do agree that our existing tunables are really complex. One more reason to not bind the new sync and userspace driven collapsing functionality to it by any means. Let's really not spread the headache to the userspace as well. -- Michal Hocko SUSE Labs