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=-13.3 required=3.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_IN_DEF_DKIM_WL 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 F0845C4320A for ; Fri, 6 Aug 2021 05:43:43 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 7F292611CA for ; Fri, 6 Aug 2021 05:43:43 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 7F292611CA Authentication-Results: mail.kernel.org; dmarc=fail (p=reject dis=none) header.from=google.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kvack.org Received: by kanga.kvack.org (Postfix) id C92DD6B006C; Fri, 6 Aug 2021 01:43:42 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id C1C3C8D0001; Fri, 6 Aug 2021 01:43:42 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id ABCF46B0072; Fri, 6 Aug 2021 01:43:42 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0209.hostedemail.com [216.40.44.209]) by kanga.kvack.org (Postfix) with ESMTP id 92ABF6B006C for ; Fri, 6 Aug 2021 01:43:42 -0400 (EDT) Received: from smtpin14.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id 1C6E4181AF5E1 for ; Fri, 6 Aug 2021 05:43:42 +0000 (UTC) X-FDA: 78443563884.14.B39E35A Received: from mail-qk1-f169.google.com (mail-qk1-f169.google.com [209.85.222.169]) by imf25.hostedemail.com (Postfix) with ESMTP id E0526B003B49 for ; Fri, 6 Aug 2021 05:43:41 +0000 (UTC) Received: by mail-qk1-f169.google.com with SMTP id t68so8790216qkf.8 for ; Thu, 05 Aug 2021 22:43:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=date:from:to:cc:subject:in-reply-to:message-id:references :mime-version; bh=nb0tzD291O2NpxD3QkJh5g66mFqozKrq3J7zV5XdneM=; b=tPJQHXxZd9eovODzKBrQ7Z1rQFYYNBRweevMY3p3T4d+8apkd/mZ4TyiXxYdN5oBHu +XFAycB1FnQvzN1zYjFLP5xEqwa6Lz90VqwX3n+BQPHkjfdn5gEk1NigAvwe9fXlD9SE dS8tKra0w06ivJObMdFJ5EFEZhWLYXTvRc4kZiH0MbWzpk2ETptYZEtSqKyavpv2dLJr zClQiwX0qS9s/UburEei25PU/qGv02H+kF28+HWanfBfj27acFef+4JzJA3Wic9Nrwxp 3xP1iJS5I0CYcBXgt9BGW6QPmuvSkHWUfkH/I9YOJXzCmWCKUTUQ86xrJrhkLbC+Mi5Y 4rMg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:in-reply-to:message-id :references:mime-version; bh=nb0tzD291O2NpxD3QkJh5g66mFqozKrq3J7zV5XdneM=; b=OjgsthSMcIuuGH66fdCHgsgreTz4lSljRPVv22B9kz9T3wUbAK1PiY1RH/U9RWn1VF cNgF5eOnK6HTEdWlTbTNNOownb7rkhRpFdLR0hV2gogNUYDG9jO9p8P8DOECU1ZGm5eF 3rhcDjT9AzjsX3EveN+FxzpPkycpSjraDp23xtTMx9tcPnP4K1yKDRZDFNu6LawyCVWy dVVsLS8QSawVl//4/rHZ2LxQxSozsotUxRPIFdCnDhnjvR6HdWd9pwVRmZs8f5JXes+R 5hhoblsdTPT//hvEdTJTgNuEMXmdne1wHyze8NGAgeQwKgLei8ZRCxzHNygOivHYnsv0 VLlQ== X-Gm-Message-State: AOAM533FnUbS9tNCmHj3MyJ2R8QTO7PfdyWSkN4Mx5khDEC9Ac2Z4Ip1 zPpm6NEFHPTQ+WA1jyd4s5n3mA== X-Google-Smtp-Source: ABdhPJwEfynqWrtytJi7KqnkQzjUoNcTR3OSX0gNN/t9rR4rDc5rHaI5jc76FJ1/rG7ENL+FdWpl4w== X-Received: by 2002:a37:5a02:: with SMTP id o2mr8487795qkb.476.1628228621102; Thu, 05 Aug 2021 22:43:41 -0700 (PDT) Received: from ripple.attlocal.net (172-10-233-147.lightspeed.sntcca.sbcglobal.net. [172.10.233.147]) by smtp.gmail.com with ESMTPSA id g4sm3970818qkk.104.2021.08.05.22.43.38 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 05 Aug 2021 22:43:40 -0700 (PDT) Date: Thu, 5 Aug 2021 22:43:37 -0700 (PDT) From: Hugh Dickins X-X-Sender: hugh@ripple.anvils To: Yang Shi cc: Hugh Dickins , 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 Subject: Re: [PATCH 06/16] huge tmpfs: shmem_is_huge(vma, inode, index) In-Reply-To: Message-ID: <749bcf72-efbd-d6c-db30-e9ff98242390@google.com> References: <2862852d-badd-7486-3a8e-c5ea9666d6fb@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: E0526B003B49 Authentication-Results: imf25.hostedemail.com; dkim=pass header.d=google.com header.s=20161025 header.b=tPJQHXxZ; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf25.hostedemail.com: domain of hughd@google.com designates 209.85.222.169 as permitted sender) smtp.mailfrom=hughd@google.com X-Stat-Signature: s4jt4x9h71d1phap3bkng3jt3qissk6w X-HE-Tag: 1628228621-291058 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, 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. > > > 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. Hugh