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 6D71FC433EF for ; Wed, 1 Jun 2022 17:26:08 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id F248F6B0089; Wed, 1 Jun 2022 13:26:07 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id ECED66B0093; Wed, 1 Jun 2022 13:26:07 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id DE4328D001C; Wed, 1 Jun 2022 13:26:07 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id CD5CD6B0089 for ; Wed, 1 Jun 2022 13:26:07 -0400 (EDT) Received: from smtpin21.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 93BDC356E2 for ; Wed, 1 Jun 2022 17:26:07 +0000 (UTC) X-FDA: 79530345174.21.0531CBE Received: from mail-pl1-f172.google.com (mail-pl1-f172.google.com [209.85.214.172]) by imf13.hostedemail.com (Postfix) with ESMTP id CAEA62006E for ; Wed, 1 Jun 2022 17:25:33 +0000 (UTC) Received: by mail-pl1-f172.google.com with SMTP id o17so2399422pla.6 for ; Wed, 01 Jun 2022 10:26:06 -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=EllVD43gc3EB5veM0G8RY5Sg1BpO50reQuExXSKSOTY=; b=JXu9sPBZynZwxMrA0gviFz/1ArT+tHzAurDPsClWn8vlVQgug7/C8JYCb0zP4F1x9j y6vNkp6aG6tX57Dn1S/em86wDpPWFQSJuXtFSprtggFcklWIYLY/3vaywWgc1X+4KwMO HQJsrc4k7F+zcwR1LwLCMGJ2cKAwQWyztWPgkuGdoppenapvpkBHoWVtmXytwQP18g2h N1Ot2vqiIaBVGavrJxOyY63ADvBEIqwuFa/Yci5HyHYaNR55H7mZp/Up0sCPTlKyvjTq zPiBWZ6mRqd3ok4eJger9UZpfJ3jQ+YsbfPO8c9vA8KAvC8l1PLa1/TI17xPiuySYwG4 aTqQ== 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=EllVD43gc3EB5veM0G8RY5Sg1BpO50reQuExXSKSOTY=; b=Ge+KbzD5U2N//GuH6W05q6ATZiC2eWVaOcfjmBB1e30kJcWg89I5tKQnSq+2M3LNr1 P60akpZnlmRQNlQjkrfh0FiuubKIY1FcnVvmUzfsjvOy1qVlYnU7mcl0wqRKrofxTXNm 2KpfawlPn7EM2IGH6VEEdMV5KiAp8wVmq151tUD/vfxikNhZYOIBT0vTYixJj+5xC65U SGbUQW+Ch6Tup+XXp/GuN+co73kMJa9ln1GVG7umBOwj1ennS+x35fu4S/83PXD1AwYR jHqA3+lFA99tBQvyU+fTco9icrDqaVfp7pZ1+7SRA9/RndsvK5tf8vuQviiJoM+maQ4g 4a6Q== X-Gm-Message-State: AOAM533Lsm3Ktz9skbdybvvgrGna6J1HYbh4LH8eQ4VaOgxDBPHOv6z3 m5SIm25n86VdssXySqlWqZAbWgowZ6m57j2/X9o= X-Google-Smtp-Source: ABdhPJyPLoFACl4m1oPetrqN31vmY7+v01uz6EPp88LVWQkGl8LelYzMnSmb0B+Vrd4QBWCNp5AI9S80NQ0YHE0NiHE= X-Received: by 2002:a17:902:aa07:b0:162:467:db94 with SMTP id be7-20020a170902aa0700b001620467db94mr567556plb.26.1654104366049; Wed, 01 Jun 2022 10:26:06 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Yang Shi Date: Wed, 1 Jun 2022 10:25:53 -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" Authentication-Results: imf13.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=JXu9sPBZ; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf13.hostedemail.com: domain of shy828301@gmail.com designates 209.85.214.172 as permitted sender) smtp.mailfrom=shy828301@gmail.com X-Rspamd-Server: rspam03 X-Rspamd-Queue-Id: CAEA62006E X-Rspam-User: X-Stat-Signature: up4uzk4hc9qzjg8o3qhociwf8thh7otz X-HE-Tag: 1654104333-41662 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 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. And shmem even has "deny" mode which has stronger semantics. > > -- > Michal Hocko > SUSE Labs