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 C574FC00140 for ; Thu, 11 Aug 2022 01:15:43 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 171C88E0002; Wed, 10 Aug 2022 21:15:43 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 122898E0001; Wed, 10 Aug 2022 21:15:43 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id F04B58E0002; Wed, 10 Aug 2022 21:15:42 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id E10418E0001 for ; Wed, 10 Aug 2022 21:15:42 -0400 (EDT) Received: from smtpin02.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id B9468AB8DA for ; Thu, 11 Aug 2022 01:15:42 +0000 (UTC) X-FDA: 79785544524.02.FCA6ABD Received: from mail-vs1-f43.google.com (mail-vs1-f43.google.com [209.85.217.43]) by imf28.hostedemail.com (Postfix) with ESMTP id 57EE4C006D for ; Thu, 11 Aug 2022 01:15:42 +0000 (UTC) Received: by mail-vs1-f43.google.com with SMTP id s129so16902581vsb.11 for ; Wed, 10 Aug 2022 18:15:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc; bh=ra3ydByKKM5WStToQCHjdG6o8mmaoU8fttyOCtEBbrY=; b=J5TW9q0DopUBP+vAlcG1ZUarFhkG5jZK+dtQw7muCjY0kiL3Bsa5ko9Ua3xMtiY0SS m60Vy/KuCLBMDsdcDgxlEgfexk8SjERDglyifjQsPg6Y/EwzxFuOZbAdhyifMIMI6EKO 9SlUuyWf2gJFiLXjay61AtRymbiwVKy6iKT2J1GbRc2BzupnqWYOhU8/dqv46DchAFg6 8ZEjBXzPgWqiscSfGxf9OtUuVaxY76JbdepF+GWdcu90AD+BTNR3lmq7wHgCj6PVeRpX 7HgJ1xWhREVNsYktLm4/8j4Rh7SiYNjJobEHnRajsabVe01247vwiim20AxwLnadYKtY atHQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc; bh=ra3ydByKKM5WStToQCHjdG6o8mmaoU8fttyOCtEBbrY=; b=k3GH3s0zdFaqjHd6GG2f87yX9jQvDX7DhFr4Aemg2k9+MHdHxDSFutoWCQbofoVlB2 Bpsu9+9czV/WIjlKPFbwfNOwMgz4+cWBZS4v5j4DAGWcezCV9WzGQMeorJjbcnbWLqcn sJcaiV/hWTpHXSyQ7pM+HbT9ek+B37x050Xrafa7iuWtVNHnxEh717+kOCzF1jTMuG9E Js1QSkeCECAna58ziykQ6v6L1qLq6qO92Yy/IkkN1QV7cHu+OkWTmB4zolsbQwcHMd2P fENPakxFL/tozo4EZb+wuFmNJNDaLWcJluxwwGbE+yytDYfVc0okYLrAKr5d/8tvdh0r P26Q== X-Gm-Message-State: ACgBeo2EKXoFBSxfVSx0sYh06Lxoz0mWyMNUA5kqrU9i7ovZ2FpSlUBa Dup+M6PeFHOGiuIrHPqdARNehLkg49Tx2IF1/NMTcg== X-Google-Smtp-Source: AA6agR5NZVsfTZXVbF4v2rKLDBrmBJSVxbyxN91rJJd5rLLglxWWasdNwM7hzebsZgDrW820ETMkLT1ire9ko9kgVzQ= X-Received: by 2002:a05:6102:5094:b0:388:6903:5f09 with SMTP id bl20-20020a056102509400b0038869035f09mr12494985vsb.46.1660180541484; Wed, 10 Aug 2022 18:15:41 -0700 (PDT) MIME-Version: 1.0 References: <20220805184016.2926168-1-alexlzhu@fb.com> <0b16dbac6444bfcdfbeb4df4280354839bfe1a8f.camel@fb.com> <1F8B9D85-A735-4832-AD58-CA4BD474248D@fb.com> <868F0874-70E8-4416-B39B-DA74C9D76A40@fb.com> In-Reply-To: From: Yu Zhao Date: Wed, 10 Aug 2022 19:15:05 -0600 Message-ID: Subject: Re: [PATCH v3] mm: add thp_utilization metrics to /proc/thp_utilization To: "Alex Zhu (Kernel)" Cc: Yang Shi , Rik van Riel , Kernel Team , "linux-mm@kvack.org" , "willy@infradead.org" , "linux-kernel@vger.kernel.org" , "akpm@linux-foundation.org" , Ning Zhang , Miaohe Lin Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable ARC-Authentication-Results: i=1; imf28.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=J5TW9q0D; spf=pass (imf28.hostedemail.com: domain of yuzhao@google.com designates 209.85.217.43 as permitted sender) smtp.mailfrom=yuzhao@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1660180542; a=rsa-sha256; cv=none; b=e6HTwYY+rBI1WVgi8+iQxkGn1jfjDfdLGBYqwGX7vzg+4W98StJoD4HpS8Z0jss9YddvL6 5/zNLHQpKt6k4qfik8a82gxbAXe3mcD0uaP/Av5gd1BOejgz8ThrCB+7vREXQQT6QtIUUx Xjrba6IT0ActofWkFv0q/vAAxi/roKg= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1660180542; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=ra3ydByKKM5WStToQCHjdG6o8mmaoU8fttyOCtEBbrY=; b=ZoMcVGLUUVMHWm2iFTE+LxsEII4mnCbnto1YuWCmfDcZ11kbPe07VAzhyz6jiNVCDH8dWq Wco7qldZCkCvDiAjGxcA4gaNDgO4B0Q++4QTeOf6W1d4kciw4Rrue8j+q2GkczFlZlAN6w N5LF7c86X8VN4e6xVM6ANigvG27QDKo= Authentication-Results: imf28.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=J5TW9q0D; spf=pass (imf28.hostedemail.com: domain of yuzhao@google.com designates 209.85.217.43 as permitted sender) smtp.mailfrom=yuzhao@google.com; dmarc=pass (policy=reject) header.from=google.com X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: 57EE4C006D X-Stat-Signature: n93btr13ocpt9pxpdd5xdwaz3qnyhbzj X-Rspam-User: X-HE-Tag: 1660180542-824427 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 Wed, Aug 10, 2022 at 6:00 PM Alex Zhu (Kernel) wrote: > > > > Which series are you talking about? I listed two series and they are > > very different on the code level. > > > > I was referring to the second patch: https://lore.kernel.org/all/16354222= 15-99394-1-git-send-email-ningzhang@linux.alibaba.com/. You mean the second patch*set* or series, the link doesn't point to a single patch :) "the second patch" could mean the second patch in that series. > This patchset adds the THP shrinking as part of shrink_lruvec in mm/vmsca= n.c. We create a new shrinker that shrinks THPs based off the results > of the scanning implemented in this thp_utilization patch. We also do not= have any of the additional knobs for controlling THP reclaim that the patc= hset above has. That seems unnecessary in the initial patch as shrinking TH= Ps that are almost entirely zero pages should only improve performance. > > I believe the resulting implementation we have is simpler and easier to u= nderstand than the above patchset. By identifying and freeing underutilized= THPs we hope to eventually deprecate madvise entirely and have THP always = enabled. > > > The 2nd patch from the first series does exactly this. > > > >> but it=E2=80=99s worth discussing whether to free zero pages immediate= ly or to add to lruvec to free eventually. > > > > And that patch can be omitted if the third link (a single patch, not a > > series) is used, which makes the workflow "add to lruvec to free > > eventually". > > > >> I believe the split_huge_page() changes could be valuable by as a patc= h by itself though. Will send that out shortly. > > Referring to this patch: https://lore.kernel.org/r/20210731063938.1391602= -1-yuzhao@google.com/. > > We do indeed do something similar to patches 1 and 3. We may be able to m= ake use of this instead, I=E2=80=99ll take a closer look. Please do. Based on what you said ("chose to free within split_huge_page()"), I very much suspect you do something similar to patch 2 as well. IIRC, that location is the best location to free subpages that only contain zeros because it covers multiple scenarios.