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 CDE4FC433F5 for ; Fri, 27 May 2022 18:10:09 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 3991C8D0003; Fri, 27 May 2022 14:10:09 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 344C18D0002; Fri, 27 May 2022 14:10:09 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 20A5D8D0003; Fri, 27 May 2022 14:10:09 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id 0EB4E8D0002 for ; Fri, 27 May 2022 14:10:09 -0400 (EDT) Received: from smtpin08.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay12.hostedemail.com (Postfix) with ESMTP id D50FC1204E4 for ; Fri, 27 May 2022 18:10:08 +0000 (UTC) X-FDA: 79512312096.08.4B909EB Received: from mail-pj1-f48.google.com (mail-pj1-f48.google.com [209.85.216.48]) by imf23.hostedemail.com (Postfix) with ESMTP id 3EDA714004A for ; Fri, 27 May 2022 18:09:45 +0000 (UTC) Received: by mail-pj1-f48.google.com with SMTP id 90-20020a17090a0fe300b001e292e2b81bso778376pjz.3 for ; Fri, 27 May 2022 11:10:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=5CwFQ9Hqxg6ecG2nMkxoLi5fRTSWrIgkwsQ5/gMlNJo=; b=NAn+GZVAd82ybekxFF3kL83vxpoivkBn0LJMvN+lYzP+0ObiGfn6fIdMRcyM+j2KWX e1K3lA2QZ/XL16dILeLTKn0Mo+ZaQ7Q/2W66wEzQQvvRK8Cao4E41gr+5YezmBqZtNjP bEIZpBwj3QIa+9P3TxBw/vEmwqGwXwDFZtl4+lUmzch7s3DdGV4E3Uqg5EZodWsrETeI 4ZvzUqq+QbBAlnIbhs0K1nZEdjLntSTcpkuHs2mF3pw2D1NnPW17prP/3YfcV+Mj8gje 6OA3Iupl80S1JrF3LsXQEd25sue25zFasqrEhtCwIgso0m1Jj0BqItBcZivLWaAAbpnc i+HA== 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=5CwFQ9Hqxg6ecG2nMkxoLi5fRTSWrIgkwsQ5/gMlNJo=; b=vcj+RYUn422+cBarx0J/0vlG9Soy0394EfrUPaPrqs488o/qypML1KR5K+kE+dtDbx ojuXFQvxeXie74KiAnU3xBCKCoBKPv8BFgly7K2nwtdviCc0ofnTw2v1aEKD7uDtvluO bKuKbrOlKxn0XVWaxta6iieieWP2MKqMryZzUOyxxe8lpccqvgEbeh1sT8hR/lk7pGlN vsErL8h8s8P1ctGCxWdzNZdCVbZUcbPC2hSl0wnblnZjDsBhgacX/WlCxtUB4nqT0NJP eLW9XRhSrEGY8lAUN+XFFVPITIx11+Q6g/shJD0qC7il7xsmTIja0zyn3s3AzS90g2dy FFdA== X-Gm-Message-State: AOAM530z+KdPc6mCPa7/HSF+Bq2LbE1sqHVztYmYqNeiYHe1WxEAcrpV maOqIqTWzoz0zJ3yD7+hq/757ZxTWVpGyOPJY7s= X-Google-Smtp-Source: ABdhPJyRtx5Z9CRlkmF5FR42u0T6QoFa2TieS9Yix5oiL8r/eTGluQbOtm6qBuhWiXxjNMPQ2SMy3KLVdGH8ChkoDAY= X-Received: by 2002:a17:902:c403:b0:163:aa4d:bab9 with SMTP id k3-20020a170902c40300b00163aa4dbab9mr542459plk.87.1653675006906; Fri, 27 May 2022 11:10:06 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Yang Shi Date: Fri, 27 May 2022 11:09:54 -0700 Message-ID: Subject: Re: [RFC] mm: MADV_COLLAPSE semantics To: Matthew Wilcox Cc: Michal Hocko , "Zach O'Keefe" , Alex Shi , David Hildenbrand , David Rientjes , Peter Xu , 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-Stat-Signature: a67q1y89g6wehr5suc7cpfzrj8rrc458 X-Rspam-User: Authentication-Results: imf23.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=NAn+GZVA; spf=pass (imf23.hostedemail.com: domain of shy828301@gmail.com designates 209.85.216.48 as permitted sender) smtp.mailfrom=shy828301@gmail.com; dmarc=pass (policy=none) header.from=gmail.com X-Rspamd-Server: rspam10 X-Rspamd-Queue-Id: 3EDA714004A X-HE-Tag: 1653674985-329692 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, May 26, 2022 at 11:30 AM 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. If we want to decouple THP allocation and khugepaged, maybe a dedicated switch for khugepaged? Just like /sys/kernel/mm/ksm/run? Or I should have not proposed a new knob :-) > > Death to tunables. Can we just delete > /sys/kernel/mm/transparent_hugepage/shmem_enabled entirely? It is used to control non-mount shm objects, for example, memfd, sys v shm. The tmpfs has mount options that control huge page eligibility. Consolidate to /sys/kernel/mm/transparent_hugepage/enabled? Maybe, but shmem_enabled has a couple of special modes: - within_size: only allocate huge pages if the page will be fully within i_size - force: enable THP for all mount tmpfs and non-mount shm - deny: do opposite of force force and deny are basically used for debugging purposes. BTW, currently file THP (readonly fs) is actually controlled by /sys/kernel/mm/transparent_hugepage/enabled since it just can be created by khugepaged for now.