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 002C8C433EF for ; Tue, 31 May 2022 21:37:29 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 5F35B6B0071; Tue, 31 May 2022 17:37:29 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 59EA96B0073; Tue, 31 May 2022 17:37:29 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 468166B0074; Tue, 31 May 2022 17:37:29 -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 34FDB6B0071 for ; Tue, 31 May 2022 17:37:29 -0400 (EDT) Received: from smtpin07.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay13.hostedemail.com (Postfix) with ESMTP id C89D06064D for ; Tue, 31 May 2022 21:37:28 +0000 (UTC) X-FDA: 79527349776.07.5443EAA Received: from mail-lj1-f170.google.com (mail-lj1-f170.google.com [209.85.208.170]) by imf21.hostedemail.com (Postfix) with ESMTP id 3018A1C004F for ; Tue, 31 May 2022 21:37:14 +0000 (UTC) Received: by mail-lj1-f170.google.com with SMTP id v9so16006658lja.12 for ; Tue, 31 May 2022 14:37:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=VXKzTkTWT3eAPMIAxQGEAKWJcKgl7EpyBJuKWVTD6Xo=; b=jAppKkGbqpT4byLb+byqYw9Yu0iznqNPByYAEON4sK6lbbb0zv1upA6SM0mYbLhLWR Sc9YOaA19DGsyFVU4OkW0HY5YpiVtAv49oM9Qa6dpF6D6jaf/3+N9kHC6aD3XPtSKpmp UWH8JS7UdJVLhuDwWVSav0fHIKIe37n9qzF2iyw01yymC7uYdDhAcMrB/Q0s/cPbcZw5 /E6f1NrnGPGErmQ8jfKRIvcHI+ljmdFxfv+wJM4VuOj7sT07Bq01sHSGJ2JDHeJSJk95 HE7Gs+RpbzyfXw5MqxnQR7tSrqo+nVzxN/yIMjlvvpgZPWDZwJha4jMyMFFuoNcOwHOR 0EAw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=VXKzTkTWT3eAPMIAxQGEAKWJcKgl7EpyBJuKWVTD6Xo=; b=ykNFc6NAU8LOeCK09x+LPQd5JZhm4flUUuIMd4wR/bNUHE+f51BIvPtPHnYYyv4uZQ kxznnuMAbQK7+cOFV6yaCAYtI8YulkSp+BDAx/btFmQ61EGfzfqiHVWRdYEYTo8jukqd O8aYNQZojjKKNzRZOdI+2ZNTEsMjvq/4O+dwuEyDBS7hNIVFn0OyWHsfJjfYehQKo5dv QFXwFd/l7pSOeuaJpP/tXyUjQ2UikRkGG+h2y07sSflIjOidZMVsftg2Bz3YK7vC1lH5 OfOpGxeEPrNvKx/kAQwN7Txz32/gOiDh8sqrE2q3++c/A617BCJBuozEbpBn5tA/4+d8 lzuQ== X-Gm-Message-State: AOAM5330HhsGUElL4erezGWT7EjwkCx5bULWV5iN99xp7MAINS4aY43M s2fbSv9M17NyeX4jKv4ntS54DT1jJwIB6Lu6NOCupQ== X-Google-Smtp-Source: ABdhPJx9ep57McGcKoXmViTD/4t0YcG2/9dYDkK1lAe7FjAHGB1eBaafS2grMi096Cnm0c5IQLJXjVCO9cXZ58x46BY= X-Received: by 2002:a2e:9216:0:b0:255:6834:dcae with SMTP id k22-20020a2e9216000000b002556834dcaemr1417838ljg.466.1654033046441; Tue, 31 May 2022 14:37:26 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: "Zach O'Keefe" Date: Tue, 31 May 2022 14:36:50 -0700 Message-ID: Subject: Re: [RFC] mm: MADV_COLLAPSE semantics To: Yang Shi , Matthew Wilcox , Michal Hocko , Peter Xu Cc: 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 Content-Type: text/plain; charset="UTF-8" X-Rspam-User: X-Rspamd-Server: rspam02 X-Rspamd-Queue-Id: 3018A1C004F X-Stat-Signature: xosznym76wfmcxoic36rnj9ou5efg1tb Authentication-Results: imf21.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=jAppKkGb; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf21.hostedemail.com: domain of zokeefe@google.com designates 209.85.208.170 as permitted sender) smtp.mailfrom=zokeefe@google.com X-HE-Tag: 1654033034-619324 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: 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. 2. Current uses of "never" a.k.a dev/debug. If (1) is false, then we've asserted that *currently* "never" is only used for development/debugging. During development of MADV_COLLAPSE, I found it necessary to disable khugepaged via a new debugfs tunable to prevent khugepaged collapsing memory before MADV_COLLAPSE could act. If MADV_COLLAPSE wasn't tied to "never", it's one less debugfs tunable we'd need. OTOH, I can still see the benefit, during debugging, of a master "no THPs" switch. If we think we'll ever want that master switch, then let's just keep "never" as said switch. 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. 4. Flexibility / separation of concerns: All else being equal, decoupling user MADV_COLLAPSE from kernel THP sysfs controls is more flexible and consistent with the rest of MADV_COLLAPSE semantics. If that's roughly accurate, and in lieu of any other critical points, if we can determine (1), then I'd prefer "never" to be tied to kernel decisions, not userspace. Any strong objections? Thanks again for your time, Zach