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 77907C433EF for ; Thu, 2 Jun 2022 16:43:44 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id C40D56B0071; Thu, 2 Jun 2022 12:43:43 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id BEEE16B0073; Thu, 2 Jun 2022 12:43:43 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id AB7BC6B0080; Thu, 2 Jun 2022 12:43:43 -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 9CDF36B0071 for ; Thu, 2 Jun 2022 12:43:43 -0400 (EDT) Received: from smtpin08.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay11.hostedemail.com (Postfix) with ESMTP id 6150D80C9D for ; Thu, 2 Jun 2022 16:43:43 +0000 (UTC) X-FDA: 79533867126.08.B98493C Received: from mail-pg1-f170.google.com (mail-pg1-f170.google.com [209.85.215.170]) by imf05.hostedemail.com (Postfix) with ESMTP id 85BFE100063 for ; Thu, 2 Jun 2022 16:43:07 +0000 (UTC) Received: by mail-pg1-f170.google.com with SMTP id u4so2240351pgk.11 for ; Thu, 02 Jun 2022 09:43:42 -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=8c9xDYUJhuXPkmLfL309TYjQjQxz7wWl8OApiWNRXiI=; b=AqqRz+m9ygfmbwVKIXZJwaI/ZPwNoUlep2Q4Oe5A7BXNNKCrNmtOGKqFuuf0fpZjsB MIWVktQN+ef4eLgZ94x89b4ByUEOmV4KLt0vD3ZP9jGySkRhK5M7DGroXmM/wYLmwbWI r8fpCzroK6LNWMtVMycBF30lqZzkSNX9EVwR0dmVI0hRuPyQ5OeQHG6nIkOrkU+jnWRG VjgqR4UWXIjPFsD2rXk5+KfvIp2S5vTotX3FU+srjGZTf5SkOhsBgVD/BJpNfG8s7cju y6Yv/1m4Gj/WRaf2holL1feImcd1u2u/D/Qb0xI4yiYWZIEXCvNNA1hgMwXJgJDOFOhJ kMIQ== 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=8c9xDYUJhuXPkmLfL309TYjQjQxz7wWl8OApiWNRXiI=; b=V/EPZ+jewt5p6F2fAPLELsOAppI1obpLeQKHQMhpFFJj/KSIqoLUZgEE+N+R6cPOJl 264aVYiM+uz+8FJ9gYK+Y7+rt/TGNSKVJ4auEDjkAh6rDkcYKvibmCwcNnMSURHpX8HS 2yREyAa9ZnCVkAMUinaQPSTk9O2k5IERlVEyuCej8MJzOqPYz9ZmhZXi61Xl5jujaE5/ mjjBA+2MGq14v0YpXvvELblCoOLzLnLN5daGr9hcD2yHH53h3lafJdmz1gUTSV48/Fmw CBUff/x0kDFwOvD0oSKVg5/Oy6WBQ0XUIP7pk/N36tP+KH06qORjPk2s2NWMLV0mcwOY U2lg== X-Gm-Message-State: AOAM532YQwkzrMdxC9iu9RTpeqbNCc8azT7CmYGYvL14aQNm+saS9Aha 9GkxtOfVujTEqUWYiOsoOPFLxc/GeBkC2E85PwY= X-Google-Smtp-Source: ABdhPJxHoeJK9GatJEjr2DMHyORABde5Ru/RFabePF8wRfrdOCSjhI8MWjII/nWXwMJalJ7NPimjZ+wtN3Fz75ODixw= X-Received: by 2002:a05:6a02:184:b0:3fc:3b43:e5da with SMTP id bj4-20020a056a02018400b003fc3b43e5damr4819163pgb.587.1654188221746; Thu, 02 Jun 2022 09:43:41 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Yang Shi Date: Thu, 2 Jun 2022 09:43:29 -0700 Message-ID: Subject: Re: [RFC] mm: MADV_COLLAPSE semantics To: Michal Hocko 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 Content-Type: text/plain; charset="UTF-8" X-Rspam-User: X-Rspamd-Server: rspam02 X-Rspamd-Queue-Id: 85BFE100063 X-Stat-Signature: r7mrp7goakg3c9e9cjt1154wr3e1bjwe Authentication-Results: imf05.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=AqqRz+m9; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf05.hostedemail.com: domain of shy828301@gmail.com designates 209.85.215.170 as permitted sender) smtp.mailfrom=shy828301@gmail.com X-HE-Tag: 1654188187-367526 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, Jun 1, 2022 at 11:56 PM Michal Hocko wrote: > > On Wed 01-06-22 10:25:53, Yang Shi wrote: > > On Wed, Jun 1, 2022 at 2:50 AM Michal Hocko wrote: > > > > > > On Tue 31-05-22 16:47:49, Yang Shi wrote: > > > > On Fri, May 27, 2022 at 2:46 AM Michal Hocko wrote: > > > [...] > > > > > I really do not see any good reason to tightly couple kernel and user > > > > > policies. Hints like MADV_{NO}HUGEPAGE are one thing and both kernel > > > > > and userspace might decide to interpret them. But binding MADV_COLLAPSE > > > > > to in kernel THP tunables just seems like pushing ourselves into the > > > > > corner. > > > > > > > > I don't mean we should tightly couple kernel and user policies. I > > > > think it is about how "never" is treated. AFAICT, typically sys admins > > > > tend to expect "never" as a global switch and they don't expect any > > > > THP allocation should happen in "never" mode even though it is > > > > requested by the users. Maybe they should not expect so in the first > > > > place. > > > > > > But this is not how the knob works, right? At least shmem has its own > > > thing. So we do not have any global kill switch for transparent huge > > > pages. > > > > Yeah, but shmem has "never" mode too, which has the same semantics and > > it is the default mode actually. Since MADV_COLLAPSE just collapse > > anon memory for now, so the discussion was focused on anon THP. But > > shmem is same. > > Do you expect MADV_COLLAPSE would stick to the anonymous memory? Are we > going to get MADV_COLLAPSE_SHMEM, MADV_COLLAPSE_FOR_REAL? No, my point is "never" mode has the same semantics for both anon and shmem. When we were talking about whether MADV_COLLAPSE should respect "never" or not, it means both. > > -- > Michal Hocko > SUSE Labs