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 63707C433F5 for ; Thu, 26 May 2022 07:12:21 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id D36708D0003; Thu, 26 May 2022 03:12:20 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id D10908D0001; Thu, 26 May 2022 03:12:20 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id BFD6B8D0003; Thu, 26 May 2022 03:12:20 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id AC9298D0001 for ; Thu, 26 May 2022 03:12:20 -0400 (EDT) Received: from smtpin01.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 8365520485 for ; Thu, 26 May 2022 07:12:20 +0000 (UTC) X-FDA: 79507025640.01.3456AC9 Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.220.29]) by imf15.hostedemail.com (Postfix) with ESMTP id E69CBA001F for ; Thu, 26 May 2022 07:11:59 +0000 (UTC) Received: from relay2.suse.de (relay2.suse.de [149.44.160.134]) by smtp-out2.suse.de (Postfix) with ESMTP id 648D41F9AC; Thu, 26 May 2022 07:12:18 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1653549138; 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=2/PjMQEkv6dA4b7GQj+N7+iQJp1elgih4rZxIFVWRbI=; b=nlTMPZEXLYQBisNctaMnL9Ef0Rp1SYsPDkFPcwkcwsO+T5wFjs8RwM9DimA5LYcoRhQn3j kedtfz+CZuN2Mxf8f9ObhExh1hXINl6ghHQC4pyXIhn4Es9LwAqXBSpTrv/6deHUiYE6T1 nboLncHfXpG6CHDtU6NzD1g4nV6Lo3o= 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 F316EA3EC6; Thu, 26 May 2022 07:12:17 +0000 (UTC) Date: Thu, 26 May 2022 09:12:17 +0200 From: Michal Hocko To: Yang Shi Cc: Zach O'Keefe , Alex Shi , David Hildenbrand , David Rientjes , Matthew Wilcox , Peter Xu , 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: Authentication-Results: imf15.hostedemail.com; dkim=pass header.d=suse.com header.s=susede1 header.b=nlTMPZEX; dmarc=pass (policy=quarantine) header.from=suse.com; spf=pass (imf15.hostedemail.com: domain of mhocko@suse.com designates 195.135.220.29 as permitted sender) smtp.mailfrom=mhocko@suse.com X-Rspam-User: X-Rspamd-Server: rspam02 X-Rspamd-Queue-Id: E69CBA001F X-Stat-Signature: z737aiu7djsem4o9wzih1g798jhpaqjt X-HE-Tag: 1653549119-63281 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 25-05-22 10:32:44, Yang Shi wrote: > On Wed, May 25, 2022 at 1:24 AM Michal Hocko wrote: > > > > On Mon 23-05-22 17:18:32, Zach O'Keefe wrote: > > [...] > > > Idea: MADV_COLLAPSE should respect VM_NOHUGEPAGE and "never" THP mode, > > > but otherwise would attempt to collapse. > > > > I do agree that {process_}madvise should fail on VM_NOHUGEPAGE. The > > process has explicitly noted that THP shouldn't be used on such a VMA > > and seeing THP could be observed as not complying with that contract. > > > > 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 respect "never" for now since it is typically used to > disable THP globally even though the mappings are madvised > (MADV_HUGEPAGE). IMHO I treat MADV_COLLAPSE as weaker MADV_HUGEPAGE > (take effect for non-madvised mappings but not flip VM_NOHUGEPAGE) + > best-effort synchronous THP collapse. MADV_HUGEPAGE is a way to tell the kernel what and how to do in future time by the kernel. MADV_COLLAPSE is a way tell what the userspace want at the moment of the call. So I do not really think they are directly related in any way except they somehow control THP. The primary question here is whether we want to support usecases which want to completely rule out THP handling by the kernel and only rely on the userspace. If yes, I do not see other way than using never global policy and rely on MADV_COLLAPSE from the userspace. Or am I missing something? > We could lift the restriction in the future if it turns out non > respecting "never" is more useful. I do not think we can change the behavior in the future without risking regressions. -- Michal Hocko SUSE Labs