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 8063DC43334 for ; Fri, 3 Jun 2022 13:26:40 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id D8E9C8D0002; Fri, 3 Jun 2022 09:26:39 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id D3DC38D0001; Fri, 3 Jun 2022 09:26:39 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C01428D0002; Fri, 3 Jun 2022 09:26:39 -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 B0D548D0001 for ; Fri, 3 Jun 2022 09:26:39 -0400 (EDT) Received: from smtpin07.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 833242118C for ; Fri, 3 Jun 2022 13:26:39 +0000 (UTC) X-FDA: 79536999318.07.A124AF9 Received: from mail-lf1-f43.google.com (mail-lf1-f43.google.com [209.85.167.43]) by imf26.hostedemail.com (Postfix) with ESMTP id 928EC14005C for ; Fri, 3 Jun 2022 13:26:34 +0000 (UTC) Received: by mail-lf1-f43.google.com with SMTP id y32so12602567lfa.6 for ; Fri, 03 Jun 2022 06:26:38 -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=LHDoxCYG60eldWRcmPDn0jAysQFkEOPFDyzWE1LULss=; b=a/CQaEYTXuMNpo+CZak9OD/MQ2yUW/osHIxNja62siYPVNiY17Qm+4HaCqMu6bk8gT bxbEhKGrXMCxUcvT7I91Q83O/DDfqQug/hPHVNNOZSjf9xzdqzuoP+Lb4W4uUZlg68go /fq7i/MUZsOdeycBc+havyf6tIjKi5U2cXDwiEFuQVSu3SirRKWK6W/aF21p9kXxhVlK l0lXS2CrIGlf4dCFgdoUWyTde2TJwWJdmADGx+jnQOr7ReE/eHaUys2Yxj/K8xqaFDxh wIRZwPh5iaptBGZ4XskWeK39rnHiUsf3v8X4BQjcObeLU0jTSKDfJycoUhK59TKQkbv8 nfsA== 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=LHDoxCYG60eldWRcmPDn0jAysQFkEOPFDyzWE1LULss=; b=5jy4QuP0uDS29lOHgUQeDlDzGjUhpn1y0RLdyDgFTtt7Jv1DEVgKRVszX5LYQaTlAt zUQs5topDVArqqAkg6HnDh/PeGu7xoL70DpJ69y72M8b4eYMIs0OdbIB1Cnv0SrP4J3N ZOQ2QMwTs3WCuNO/zsrfDmo8ZG5qG/d1yfIOB/U8+R40+I23W/ejEBPEYx8k5IK+XqVb GZhSVlgqdnMFX8EVWjgeZ/COJZkVPRRkvc/+1QPR5uWYCD4ocgbVnvmC7uoOZg2x8lZq 4dXQUZUgl4eEpub00mmJZOd0JDazIoUP+5SqYPVlLVDbqui2LVJDoqCyoZUXOG/pMslH uRFA== X-Gm-Message-State: AOAM533IscrzDruK9jxboC09aE14U6KD9Dn4DNsS34128wVCgOzlI31m jfFB/ASiMpPygzBYNU+SCP1e86wMJ0zlV0wBVivaMQ== X-Google-Smtp-Source: ABdhPJyPa0732lhu73JhqHZxJ97im98UeYqu2JhYCPI+kTk9OOFCOOUYiznGjQoHkPdeRznjY5e00UtvJmbxrNWSzrw= X-Received: by 2002:a19:6742:0:b0:479:17b7:afa6 with SMTP id e2-20020a196742000000b0047917b7afa6mr2728531lfj.159.1654262797168; Fri, 03 Jun 2022 06:26:37 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: "Zach O'Keefe" Date: Fri, 3 Jun 2022 06:26:00 -0700 Message-ID: Subject: Re: [RFC] mm: MADV_COLLAPSE semantics To: Yang Shi Cc: Michal Hocko , 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-Stat-Signature: mf3ht9qty5mz7beqm41z6efa3jou196t X-Rspam-User: Authentication-Results: imf26.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b="a/CQaEYT"; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf26.hostedemail.com: domain of zokeefe@google.com designates 209.85.167.43 as permitted sender) smtp.mailfrom=zokeefe@google.com X-Rspamd-Server: rspam09 X-Rspamd-Queue-Id: 928EC14005C X-HE-Tag: 1654262794-612766 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, Jun 2, 2022 at 9:43 AM Yang Shi wrote: > > 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. Ya, this is a good point, and something I honestly overlooked originally when posting this thread. > > > > -- > > Michal Hocko > > SUSE Labs