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 DFBDCC433F5 for ; Tue, 24 May 2022 17:08:54 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 7E56C8D0002; Tue, 24 May 2022 13:08:54 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 790DD8D0001; Tue, 24 May 2022 13:08:54 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 6A5208D0002; Tue, 24 May 2022 13:08:54 -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 565288D0001 for ; Tue, 24 May 2022 13:08:54 -0400 (EDT) Received: from smtpin29.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 1573234F71 for ; Tue, 24 May 2022 17:08:54 +0000 (UTC) X-FDA: 79501271388.29.16095E1 Received: from mail-lj1-f180.google.com (mail-lj1-f180.google.com [209.85.208.180]) by imf01.hostedemail.com (Postfix) with ESMTP id 9155640039 for ; Tue, 24 May 2022 17:08:50 +0000 (UTC) Received: by mail-lj1-f180.google.com with SMTP id r3so14778263ljd.7 for ; Tue, 24 May 2022 10:08:53 -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=beHXG83UuQTLLMPkDo53PV66CFfsXmFqJpzQ6HKz9n8=; b=altuhwR1LrcObG0yk2VkDdFmH500owzGn1cni/lFjKaLb8vON/7amOKBnhxJ3mg2VX J6blh2A4VCrY++HQ8pimKUVvsZpaiBy3MWruz1f6aCpJPNOtc5Gyow6gF2PLI0apSUX+ OAEoUOB5jrpIhwb8xc++99Y3wmhvuhgmZ7l94Sl3OTBHr0Oj1DNrrFclgoIKMW5CAkzg 2ixv3H2qH6xXxqVQxkN4rkQyqHjwRn5bR2VNz+xZbNFBb1JM2+0q+kUf2oe26mOInmtZ kOZi3HPHCe9MnDM1t/V8WrxoiRWVhM1z4wIOW4ceFNW5FmN7r/Dj1YvP36sXDeDrcQsv pG1Q== 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=beHXG83UuQTLLMPkDo53PV66CFfsXmFqJpzQ6HKz9n8=; b=hotQxWa06GBzrDqjFv9k6EKcviP394kxzpB0a2mpJ9mKgA8WUtZWcTvpvoQ5npiCUY 74vIZdjvGBR8lAMnGfCfZ+uNE4xJHttKTB54zsJhm0jGgK4QKcYTmSsq7pyZnlQZlN1B RSYw35PYFQprxHL2EPjNA3zubMdPkS9r3RZVncjrd1olRGVzxtGfodj4ubGSGxxaQSnP +pfG24nlCCJdyLjSFodA6FyI4gHRXN2K+S4vMD/GR7euzWhQ6o3P1P/Rp92kJOkhGooo iKWRt/nB6mVnfil4fScF2OztIavbptq213UQ1ExjDXbNjOZePu1P8Hm6X3au88mgghK9 GtiQ== X-Gm-Message-State: AOAM532cpxdQKSy8Sc/v2NZyTrPMrIu8+BCHTTXECbr9/RIDi/jSqdPM OAarMTvVkDw+PeSrOa4cBichIPMLP+pTChCP5RUrTg== X-Google-Smtp-Source: ABdhPJyqXxGH5WovSFDpBuzba3/weQUeRdY42slPdoIOdOM2zOuR0pvM4YAfNYKZjwaVULDRl9ccuRv7PJqnjzSurDY= X-Received: by 2002:a05:651c:4c9:b0:253:fc0b:5038 with SMTP id e9-20020a05651c04c900b00253fc0b5038mr1953358lji.278.1653412131895; Tue, 24 May 2022 10:08:51 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: "Zach O'Keefe" Date: Tue, 24 May 2022 10:08:15 -0700 Message-ID: Subject: Re: [RFC] mm: MADV_COLLAPSE semantics To: Peter Xu Cc: Alex Shi , David Hildenbrand , David Rientjes , Matthew Wilcox , Michal Hocko , Song Liu , Yang Shi , linux-mm@kvack.org, rongwei.wang@linux.alibaba.com, Andrea Arcangeli , Axel Rasmussen , Hugh Dickins , "Kirill A. Shutemov" , Minchan Kim , SeongJae Park , Pasha Tatashin Content-Type: text/plain; charset="UTF-8" Authentication-Results: imf01.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=altuhwR1; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf01.hostedemail.com: domain of zokeefe@google.com designates 209.85.208.180 as permitted sender) smtp.mailfrom=zokeefe@google.com X-Rspam-User: X-Rspamd-Server: rspam02 X-Rspamd-Queue-Id: 9155640039 X-Stat-Signature: jnxpnsuyuykumk876d4y85th9zczom91 X-HE-Tag: 1653412130-899672 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 Tue, May 24, 2022 at 6:26 AM Peter Xu wrote: > > On Mon, May 23, 2022 at 05:18:32PM -0700, Zach O'Keefe wrote: > > (*) If we could verify that "never" THP mode was used _only_ for > > debugging, then I'd actually opt to ignore "never" in MADV_COLLAPSE. > > Some real time users may have used thp=never to make sure there's no > pgtable uncertainty in all cases (and pages will always be mlocked for the > RT apps, so pre-faulted). > Thanks for the great example here! > Debattably it's the same as TRANSPARENT_HUGEPAGE=n but the user might want > to use the same kernel with other purpose where thp could still be wanted? > I've no solid clue. It's just that as long as we have the knob taking > "never" as an option then people may be using it, I'm afraid. > > "no" is indeed stronger than "yes" in many cases, at least for thp it's > always like that: thp=never will guarantee no thp globally, while > thp=always will only provide thp when it's still possible. The same to > MADV_[NO]HUGEPAGE but just for vmas. From that POV I think your current > plan looks reasonable on respecting "no"s more than "yes"s for both layers. > This makes sense to me. Best to be safe / follow existing "strong no" convention. Again, thanks for taking the time to read and provide feedback - very much appreciated. Best, Zach > Thanks, > > -- > Peter Xu >