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.8 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 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 E0392C4338F for ; Fri, 6 Aug 2021 17:57:47 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 3DB77611C3 for ; Fri, 6 Aug 2021 17:57:47 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 3DB77611C3 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kvack.org Received: by kanga.kvack.org (Postfix) id 6760D6B006C; Fri, 6 Aug 2021 13:57:46 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 6232F8D0001; Fri, 6 Aug 2021 13:57:46 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 4EAC06B0072; Fri, 6 Aug 2021 13:57:46 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0054.hostedemail.com [216.40.44.54]) by kanga.kvack.org (Postfix) with ESMTP id 324686B006C for ; Fri, 6 Aug 2021 13:57:46 -0400 (EDT) Received: from smtpin18.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id C4A1F1C9B5 for ; Fri, 6 Aug 2021 17:57:45 +0000 (UTC) X-FDA: 78445413690.18.8D1126C Received: from mail-ej1-f50.google.com (mail-ej1-f50.google.com [209.85.218.50]) by imf12.hostedemail.com (Postfix) with ESMTP id 7629010055A0 for ; Fri, 6 Aug 2021 17:57:45 +0000 (UTC) Received: by mail-ej1-f50.google.com with SMTP id qk33so16325038ejc.12 for ; Fri, 06 Aug 2021 10:57:45 -0700 (PDT) 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; bh=e6yu4POMRnVahz+1Lp2VPniantg+hltxCjShVbMiYBI=; b=kyHm0266NGCpJDUk2RCfS7EhmsuhBQ+aqLDWr6WH9ZzEgbMeskSMWsZRpU1yrngFm4 Mn/PdT+ZXHpQBdPACrXLec0Lf5Fx2kNY0s7jxuzExL6XlKnn8no6fPNzTA/Vz7S4Ujhv +MGARosjoV21ijQ+UjFgPWYgZ3RltCw+sy6ZVTIZnepC6ntCFfopOgJtZVFS6XD1KrbL sqMve6VzxDyRiwKWsCpWeXhc+m44v6wUeI/91Dk5U2qvIPizBhaa8ukQzZ/8Kd/zfUF+ 6syAT1xdat+UZqj++lu9a/yFQyznf9YcYTwRpxOaWheL2mq5FBfd3s0WKXpNOVA7mzKF gDBA== 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; bh=e6yu4POMRnVahz+1Lp2VPniantg+hltxCjShVbMiYBI=; b=o6aJD/pxOyYQ822Nu5mjn97Oz/iDOwFisW9hGYTVBxoVLIgh5AGfm2g9hC75LHYWGw WbtZZrdG/KgElObaBQ/T0Ms9sn/69gPMXja94tAz41vV+VlpyM2PtLBRZ8vgCEaHh2by yNb/wh4EICOa8a9ZLiH+iwWIcyYY41KFUbXrIstvjlwtDYvjz9Vq+JM/p/hRZ43j6dE6 FxeSKdJfUBtQig4qEeI2uZMN1+EyHBL+0UfB3k7soS3DikOrXH7DGTi95Nda8vOWKN5R WS5ibi9ngalCwkuPZSi4cSpKIuRJuXNZkaSr3tVNUmQchvLSZvLXxEMXuJtcP3SISRl5 V3Bg== X-Gm-Message-State: AOAM532QYBYoCoK4/oMDU3YZwp/W29chuCULtcNlkJqI5epVzO2fF5tP ZsSLprY3A4MZKHDFqzqnS0GTYL0PiP4UMxLyIb4= X-Google-Smtp-Source: ABdhPJznXWLKfoZB6ywf3PHaxFFTF+rjYHPnGDtCk5ZfySRuvDf7YmVSwQE9PAQHdyreWuzcuCGAI6DwPTcHO0mVlwU= X-Received: by 2002:a17:906:1919:: with SMTP id a25mr10825003eje.161.1628272664305; Fri, 06 Aug 2021 10:57:44 -0700 (PDT) MIME-Version: 1.0 References: <2862852d-badd-7486-3a8e-c5ea9666d6fb@google.com> <749bcf72-efbd-d6c-db30-e9ff98242390@google.com> In-Reply-To: <749bcf72-efbd-d6c-db30-e9ff98242390@google.com> From: Yang Shi Date: Fri, 6 Aug 2021 10:57:32 -0700 Message-ID: Subject: Re: [PATCH 06/16] huge tmpfs: shmem_is_huge(vma, inode, index) To: Hugh Dickins Cc: Andrew Morton , Shakeel Butt , "Kirill A. Shutemov" , Miaohe Lin , Mike Kravetz , Michal Hocko , Rik van Riel , Christoph Hellwig , Matthew Wilcox , "Eric W. Biederman" , Alexey Gladkov , Chris Wilson , Matthew Auld , Linux FS-devel Mailing List , Linux Kernel Mailing List , linux-api@vger.kernel.org, Linux MM Content-Type: text/plain; charset="UTF-8" X-Rspamd-Server: rspam03 X-Rspamd-Queue-Id: 7629010055A0 Authentication-Results: imf12.hostedemail.com; dkim=pass header.d=gmail.com header.s=20161025 header.b=kyHm0266; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf12.hostedemail.com: domain of shy828301@gmail.com designates 209.85.218.50 as permitted sender) smtp.mailfrom=shy828301@gmail.com X-Stat-Signature: sc5yqdpfnqwkgenbgcg1jbjifyi5r8e6 X-HE-Tag: 1628272665-991593 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, Aug 5, 2021 at 10:43 PM Hugh Dickins wrote: > > On Thu, 5 Aug 2021, Yang Shi wrote: > > > > By rereading the code, I think you are correct. Both cases do work > > correctly without leaking. And the !CONFIG_NUMA case may carry the > > huge page indefinitely. > > > > I think it is because khugepaged may collapse memory for another NUMA > > node in the next loop, so it doesn't make too much sense to carry the > > huge page, but it may be an optimization for !CONFIG_NUMA case. > > Yes, that is its intention. > > > > > However, as I mentioned in earlier email the new pcp implementation > > could cache THP now, so we might not need keep this convoluted logic > > anymore. Just free the page if collapse is failed then re-allocate > > THP. The carried THP might improve the success rate a little bit but I > > doubt how noticeable it would be, may be not worth for the extra > > complexity at all. > > It would be great if the new pcp implementation is good enough to > get rid of khugepaged's confusing NUMA=y/NUMA=n differences; and all > the *hpage stuff too, I hope. That would be a welcome cleanup. The other question is if that optimization is worth it nowadays or not. I bet not too many users build NUMA=n kernel nowadays even though the kernel is actually running on a non-NUMA machine. Some small devices may run NUMA=n kernel, but I don't think they actually use THP. So such code complexity could be removed from this point of view too. > > > > > Collapse failure is not uncommon and leaking huge pages gets noticed. > > After writing that, I realized how I'm almost always testing a NUMA=y > kernel (though on non-NUMA machines), and seldom try the NUMA=n build. > So did so to check no leak, indeed; but was surprised, when comparing > vmstats, that the NUMA=n run had done 5 times as much thp_collapse_alloc > as the NUMA=y run. I've merely made a note to look into that one day: > maybe it was just a one-off oddity, or maybe the incrementing of stats > is wrong down one path or the other. Yeah, probably. > > Hugh