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 X-Spam-Level: X-Spam-Status: No, score=-2.7 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id E39B4C433E0 for ; Mon, 8 Mar 2021 20:18:33 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 62CAF65285 for ; Mon, 8 Mar 2021 20:18:33 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 62CAF65285 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id A8FB78D0071; Mon, 8 Mar 2021 15:18:32 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id A65F58D001D; Mon, 8 Mar 2021 15:18:32 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 907288D0071; Mon, 8 Mar 2021 15:18:32 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0226.hostedemail.com [216.40.44.226]) by kanga.kvack.org (Postfix) with ESMTP id 73C7A8D001D for ; Mon, 8 Mar 2021 15:18:32 -0500 (EST) Received: from smtpin18.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id 364591DF6 for ; Mon, 8 Mar 2021 20:18:32 +0000 (UTC) X-FDA: 77897819664.18.12EE059 Received: from mail-ed1-f51.google.com (mail-ed1-f51.google.com [209.85.208.51]) by imf05.hostedemail.com (Postfix) with ESMTP id 2EFA3E0001B4 for ; Mon, 8 Mar 2021 20:18:31 +0000 (UTC) Received: by mail-ed1-f51.google.com with SMTP id b13so16682140edx.1 for ; Mon, 08 Mar 2021 12:18:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=xEus+DE8Y+6Hz6uQIfLVbNTiNLnC290XtZObCVJPizs=; b=EUVXoExh+Sb7GQH0WJBF5KGZnJitXfHwiaDIy6OqIYHVHSMsE6NID/Dk7v9elZrL6n zdORUiumYCV3BCuMKSntef+syeMrVg9KsSwm3StkbqdR7HZE/Pad+HWOWrBkOfg8L5+8 i82xbDS+amkMh/WqZG1p70eWrMvppel8joPTAj7xLH56LXvjv0j8n5j78N8K02pI2Jw8 OyK5PQVFDWKWJouNCkY8vat1MWuDI/Z+Zqbk295UzLnV9GB0JJeqpM0hQ0xxVvZ6nPG3 xhTCmGExBmO2TN9GT/YUXdQZ13BADFWkSOGKe0QAwqGJ+luzfvs5UnkxxWLYzlWrzCQ2 5UGQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=xEus+DE8Y+6Hz6uQIfLVbNTiNLnC290XtZObCVJPizs=; b=Bahl8RROBPIhxzVgCA2l1VqDoHGup94ovDqG7I3CEwQLj7v1ikAIgdk96fqEwAE/Ct Z2x7xuMEQSSLXZU5jOuLkCn0L7bxFNUYZ6QLwONRdhr55KrfrwqIaUbTzZMc2YjozNXU M5zt4gGpJOfJvqPsbQH56HK/J3Yj1lY0mJ4HzPPHRZ0f9xp8i9xhVUdF4uZjDANRmvKd FiAbcKJv8s2IMEAk/la+Jbgoah6VJNo6nm5qyFlpeKtV4sELJwla1xK77grBzbUYDMep qbaSfG0q7RJeOEi0uRUajBLdWLvUZCXXIb/Dm0d/Oe0gRlgTfLAdKIu62Se2U9zg+jnF CdLA== X-Gm-Message-State: AOAM532oZHMJQWSJazWIeFgwuOLEkMdAk5hhULPCI3bygDV3m7TCEkr2 ITjxdc2nDuqkybMJ3lUWONSYtFocCQuspHiRShU= X-Google-Smtp-Source: ABdhPJw5NWT9CCgMIQc0lxRIDTONwFmO58W+E2Y3C5NdaO4UczGWnwZti6R+vaARQCjY4NUrZjX7RTqffmarYubxta4= X-Received: by 2002:aa7:c403:: with SMTP id j3mr321346edq.137.1615234710445; Mon, 08 Mar 2021 12:18:30 -0800 (PST) MIME-Version: 1.0 References: <20210308152221.28555-1-zi.yan@sent.com> <79458c46-b4b9-332b-77f7-44371502cbeb@redhat.com> <8039e1d7-3442-f133-f4f6-fe934f02122e@redhat.com> <9A4EF5F7-1BFF-4F8D-80B8-B559C05635BE@nvidia.com> In-Reply-To: From: Yang Shi Date: Mon, 8 Mar 2021 12:18:18 -0800 Message-ID: Subject: Re: [PATCH] mm: huge_memory: a new debugfs interface for splitting THP tests. To: David Hildenbrand Cc: Zi Yan , Linux MM , Linux Kernel Mailing List , linux-kselftest@vger.kernel.org, "Kirill A . Shutemov" , Andrew Morton , Shuah Khan , John Hubbard , Sandipan Das , David Rientjes , Alex Shi Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Stat-Signature: 6apa5e81am45bbsxk8oas8rg3r1uhmui X-Rspamd-Server: rspam02 X-Rspamd-Queue-Id: 2EFA3E0001B4 Received-SPF: none (gmail.com>: No applicable sender policy available) receiver=imf05; identity=mailfrom; envelope-from=""; helo=mail-ed1-f51.google.com; client-ip=209.85.208.51 X-HE-DKIM-Result: pass/pass X-HE-Tag: 1615234711-102286 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 Mon, Mar 8, 2021 at 11:30 AM David Hildenbrand wrote: > > On 08.03.21 20:11, Yang Shi wrote: > > On Mon, Mar 8, 2021 at 11:01 AM Zi Yan wrote: > >> > >> On 8 Mar 2021, at 13:11, David Hildenbrand wrote: > >> > >>> On 08.03.21 18:49, Zi Yan wrote: > >>>> On 8 Mar 2021, at 11:17, David Hildenbrand wrote: > >>>> > >>>>> On 08.03.21 16:22, Zi Yan wrote: > >>>>>> From: Zi Yan > >>>>>> > >>>>>> By writing ",," to > >>>>>> /split_huge_pages_in_range_pid, THPs in the process with = the > >>>>>> given pid and virtual address range are split. It is used to test > >>>>>> split_huge_page function. In addition, a selftest program is added= to > >>>>>> tools/testing/selftests/vm to utilize the interface by splitting > >>>>>> PMD THPs and PTE-mapped THPs. > >>>>> > >>>>> Won't something like > >>>>> > >>>>> 1. MADV_HUGEPAGE > >>>>> > >>>>> 2. Access memory > >>>>> > >>>>> 3. MADV_NOHUGEPAGE > >>>>> > >>>>> Have a similar effect? What's the benefit of this? > >>>> > >>>> Thanks for checking the patch. > >>>> > >>>> No, MADV_NOHUGEPAGE just replaces VM_HUGEPAGE with VM_NOHUGEPAGE, > >>>> nothing else will be done. > >>> > >>> Ah, okay - maybe my memory was tricking me. There is some s390x KVM c= ode that forces MADV_NOHUGEPAGE and force-splits everything. > >>> > >>> I do wonder, though, if this functionality would be worth a proper us= er interface (e.g., madvise), though. There might be actual benefit in havi= ng this as a !debug interface. > >>> > >>> I think you aware of the discussion in https://lkml.kernel.org/r/d098= c392-273a-36a4-1a29-59731cdf5d3d@google.com > >> > >> Yes. Thanks for bringing this up. > >> > >>> > >>> If there will be an interface to collapse a THP -- "this memory area = is worth extra performance now by collapsing a THP if possible" -- it might= also be helpful to have the opposite functionality -- "this memory area is= not worth a THP, rather use that somehwere else". > >>> > >>> MADV_HUGE_COLLAPSE vs. MADV_HUGE_SPLIT > >> > >> I agree that MADV_HUGE_SPLIT would be useful as the opposite of COLLAP= SE when user might just want PAGESIZE mappings. > >> Right now, HUGE_SPLIT is implicit from mapping changes like mprotect o= r MADV_DONTNEED. > > > > IMHO, it sounds not very useful. MADV_DONTNEED would split PMD for any > > partial THP. If the range covers the whole THP, the whole THP is going > > to be freed anyway. All other places in kernel which need split THP > > have been covered. So I didn't realize any usecase from userspace for > > just splitting PMD to PTEs. > > THP are a limited resource. So indicating which virtual memory regions > are not performance sensitive right now (e.g., cold pages in a databse) > and not worth a THP might be quite valuable, no? Such functionality could be achieved by MADV_COLD or MADV_PAGEOUT, right? Then a subsequent call to MADV_NOHUGEPAGE would prevent from collapsing or allocating THP for that area. > > -- > Thanks, > > David / dhildenb >