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 D08DFC433F5 for ; Thu, 10 Mar 2022 18:59:02 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 5B9288D0002; Thu, 10 Mar 2022 13:59:02 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 569468D0001; Thu, 10 Mar 2022 13:59:02 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 408908D0002; Thu, 10 Mar 2022 13:59:02 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (relay.a.hostedemail.com [64.99.140.24]) by kanga.kvack.org (Postfix) with ESMTP id 311F28D0001 for ; Thu, 10 Mar 2022 13:59:02 -0500 (EST) Received: from smtpin07.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id F2B61220BF for ; Thu, 10 Mar 2022 18:59:01 +0000 (UTC) X-FDA: 79229388882.07.E474917 Received: from mail-lj1-f169.google.com (mail-lj1-f169.google.com [209.85.208.169]) by imf01.hostedemail.com (Postfix) with ESMTP id 8389440017 for ; Thu, 10 Mar 2022 18:59:01 +0000 (UTC) Received: by mail-lj1-f169.google.com with SMTP id u3so9152252ljd.0 for ; Thu, 10 Mar 2022 10:59:01 -0800 (PST) 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=mioFAwfmO1Iqpo4GttCUpqoWlneqYjr6rKmIMLjdfr8=; b=i0F03pndQvlERnXoejTYLIqf0sgVuD+AMD6mu/BZTENa3bkYf2GMAal9kdA7q8g4rE HYeVL+wC99+S3ECpyAWsWrG0cUmkKjOOUD/aOtBn+svQ0EYWK7ZTFtTnwygy6sngZsQu Ps9LzQ596s3oyR8HyylQwa64eBpGGMrrko+6ByJ9r5eaIhMJshS0mENrxlWEupV4q+sV KCnqLkhxH+OLasqsfr/OfNJjReSkz9hbYCF1jECH1buLd09CIaIAeXHt5zSbahV0UyMZ /FOhrxeTbCCYBDmLQaeoacwQNlkRv9dK/qx3ekN1Ityp0MSwpK65xzjC89bvvz8+Lpgd RsvA== 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=mioFAwfmO1Iqpo4GttCUpqoWlneqYjr6rKmIMLjdfr8=; b=lzC8eJLSYEijEaY5Hkv22WnnHJYlo+7Op0MuOJqUoyGzIyVhI54hu4z2Ni41790TwX tsj/qr+qpn/QJQpQ95rdrQJR2xshIJQcMFAyWfUjgUCVQ4tTyKCaM/hfKdrG3qAL+GZJ JN1DoiQ/IDdjVYRyY96t3g9amWoPG/SaYyE7ICtVnzwXD6tUAwjWA7MvoVisUPRvc5Pn 2AQHnauQOneiRkNiOS6RSWBjbCHL6djTjTZcWElQuzf2aQkWRxqZPM3w4SXMvncfslrC qz7aDHNA0l08blJ49LWpt5WJgPhe7SlDRKmrY7n8aMZ57tNcdTKsOr5cQHwCueXvYcpu Q9bw== X-Gm-Message-State: AOAM533GRXYr1auHdfbS8h0+HUfTklPtlJRUrQPXjknT6QAXdP5ne5Kl UfrwrvsDiF7y1YSQJVCNe9ZQLp14Zqd0B5eIJmUqlQ== X-Google-Smtp-Source: ABdhPJyYT8HcUtPc2CVp+sIeNkmPsO1L4vDVbziEfZRysFJDAy7LMu/F4F6NLinGhOG3DreHD3QrOC4I4jfJSJUZaMI= X-Received: by 2002:a2e:b989:0:b0:248:5a5:cb64 with SMTP id p9-20020a2eb989000000b0024805a5cb64mr3721114ljp.183.1646938739903; Thu, 10 Mar 2022 10:58:59 -0800 (PST) MIME-Version: 1.0 References: <20220308213417.1407042-1-zokeefe@google.com> <20220308213417.1407042-8-zokeefe@google.com> In-Reply-To: From: "Zach O'Keefe" Date: Thu, 10 Mar 2022 10:58:23 -0800 Message-ID: Subject: Re: [RFC PATCH 07/14] mm/khugepaged: add vm_flags_ignore to hugepage_vma_revalidate_pmd_count() To: David Rientjes , Yang Shi Cc: Alex Shi , David Hildenbrand , Michal Hocko , Pasha Tatashin , SeongJae Park , Song Liu , Vlastimil Babka , Zi Yan , Linux MM , Andrea Arcangeli , Andrew Morton , Arnd Bergmann , Axel Rasmussen , Chris Kennelly , Chris Zankel , Helge Deller , Hugh Dickins , Ivan Kokshaysky , "James E.J. Bottomley" , Jens Axboe , "Kirill A. Shutemov" , Matthew Wilcox , Matt Turner , Max Filippov , Miaohe Lin , Minchan Kim , Patrick Xia , Pavel Begunkov , Peter Xu , Thomas Bogendoerfer Content-Type: text/plain; charset="UTF-8" X-Rspam-User: X-Rspamd-Server: rspam02 X-Rspamd-Queue-Id: 8389440017 X-Stat-Signature: jkc1kun4pk7cute57cagwktbsqx6n7td Authentication-Results: imf01.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=i0F03pnd; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf01.hostedemail.com: domain of zokeefe@google.com designates 209.85.208.169 as permitted sender) smtp.mailfrom=zokeefe@google.com X-HE-Tag: 1646938741-413162 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000001, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Thu, Mar 10, 2022 at 10:46 AM David Rientjes wrote: > > On Thu, 10 Mar 2022, Yang Shi wrote: > > > > This separates "async-hint" vs "sync-explicit" madvise requests. > > > MADV_[NO]HUGEPAGE are hints, and together with thp settings, advise > > > the kernel how to treat memory in the future. The kernel uses > > > VM_[NO]HUGEPAGE to aid with this. MADV_COLLAPSE, as an explicit > > > request, is free to define its own defrag semantics. > > > > > > This would allow flexibility to separately define async vs sync thp > > > policies. For example, highly tuned userspace applications that are > > > sensitive to unexpected latency might want to manage their hugepages > > > utilization themselves, and ask khugepaged to stay away. There is no > > > way in "always" mode to do this without setting VM_NOHUGEPAGE. > > > > I don't quite get why you set THP to always but don't want to > > khugepaged do its job. It may be slow, I think this is why you > > introduce MADV_COLLAPSE, right? But it doesn't mean khugepaged can't > > scan the same area, it just doesn't do any real work and waste some > > cpu cycles. But I guess MADV_COLLAPSE doesn't prevent the PMD/THP from > > being split, right? So khugepaged still plays a role to re-collapse > > the area without calling MADV_COLLAPSE over again and again. > > > > My only real concern for MADV_COLLAPSE was when the span being collapsed > includes a mixture of both VM_HUGEPAGE and VM_NOHUGEPAGE. Does this > collapse over the eligible memory or does it fail entirely? > > I'd think it was the former, that we should respect VM_NOHUGEPAGE and only > collapse eligible memory when doing MADV_COLLAPSE but now userspace > struggles to know whether it was a partial collapse because of > ineligiblity or because we just couldn't allocate a hugepage. > > It has the information to figure this out on its own, so given the use of > VM_NOHUGEPAGE for non-MADV_NOHUGEPAGE purposes, I think it makes sense to > simply ignore these vmas as part of the collapse request. Ignoring these vmas SGTM. Thanks All.