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 32CB5C00140 for ; Wed, 10 Aug 2022 21:56:45 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 6CBEB8E0002; Wed, 10 Aug 2022 17:56:44 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 67C338E0001; Wed, 10 Aug 2022 17:56:44 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 51BCD8E0002; Wed, 10 Aug 2022 17:56:44 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 401908E0001 for ; Wed, 10 Aug 2022 17:56:44 -0400 (EDT) Received: from smtpin11.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id D15EF1C6F00 for ; Wed, 10 Aug 2022 21:56:43 +0000 (UTC) X-FDA: 79785043086.11.2688CE4 Received: from mail-vs1-f45.google.com (mail-vs1-f45.google.com [209.85.217.45]) by imf29.hostedemail.com (Postfix) with ESMTP id 6DD10120176 for ; Wed, 10 Aug 2022 21:56:43 +0000 (UTC) Received: by mail-vs1-f45.google.com with SMTP id m67so16521386vsc.12 for ; Wed, 10 Aug 2022 14:56:43 -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=i0a/3GKlBKDqjZOUqm+Ai/MPjy54p3lvrq9RguS53iA=; b=p0rpGImMY6AW4jCBiEqMSb0qwsFuwvHKhj3DlbCGo7b95rUc/MVMhUea3sfVA91KGE 3MYgP/iPPW9Sf1KNPwPVQvNhO+5VoESePEIyM4lu5Oh9wZB17UQQwGdODxlvVp7oY8IM U8DPwu0+3jei0TPQW6eCol6sjxionnEYdRgy7bzzr5nbR3z3y57fgJ9gRKHlL2SDI8Se +8Y3BktA1nOfDxL4c2HczfjpBmE2tmpz/d2lJlk5Y8W8W5h6LKRErCD7uoZ2OGUhCwRu dzIR233tPvE9cEndER1VNHPDVv3VhJW1cxU7K5xSnfxwoD1KZS2DPOgekhqhjWaD/aVW +wwQ== 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=i0a/3GKlBKDqjZOUqm+Ai/MPjy54p3lvrq9RguS53iA=; b=73AxCzQW0I3FgwSmCyp5OuTRtoVOHzkjgRJHE4DBmRhyoQ/6E4IGL90QBO6w2rb3O7 9653iMC2QNZOqo26Et4Svnqxx7RMVg1vmdMEpbTD38kLJ98VE3KIsNbl/gN9N8rh+LUa ZZOCvxfE8eT2Ee4LcZlQo+XlMaQfztlQQYJ3vis0LgqCDztD2zc4E10ATrfTOxvhoKYp bglLbfQmkAlzHgm4Ko37Halbg6n/7n/65NPLYDvpT0CkTiPtSFzHo8Prz/JRYs1/hC/D ScHF92hQhurF3mDyDHgOVgx3TLzCkCsYNsEIgxKSVdMaM6K+NM3sNelB5NoBNoMLotRs OEbA== X-Gm-Message-State: ACgBeo3AevOwGPxVfBQy80Ubv96QdE49rZczVFnI3xMj26UI0SFxlYb3 sXkM8mDzpt52Vb9xLtKQABdtsjwxL7xVrVRyVNlR8Q== X-Google-Smtp-Source: AA6agR7W0EvdbUq2s9aUjkbWzeWjHNltyirgA+BwvcPFvp6v5Ud3fG5MI4n2K6ySHFMfGlZPQlrvTtVsZeJTq8gSsV4= X-Received: by 2002:a05:6102:665:b0:387:b34:d579 with SMTP id z5-20020a056102066500b003870b34d579mr11978710vsf.50.1660168602569; Wed, 10 Aug 2022 14:56:42 -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: <868F0874-70E8-4416-B39B-DA74C9D76A40@fb.com> From: Yu Zhao Date: Wed, 10 Aug 2022 15:56:06 -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; imf29.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=p0rpGImM; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf29.hostedemail.com: domain of yuzhao@google.com designates 209.85.217.45 as permitted sender) smtp.mailfrom=yuzhao@google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1660168603; a=rsa-sha256; cv=none; b=lI9fhJU2+WsDj32OAggls3uc2GFEOFqCXe+leVhCLUvmSyi5hjinFZhB2/B3WKbeL+fNA8 +1S8LFaQwpXlcwbSykiikZy8ZLjolxc5gR60jhXiWPTfiyauIZHn8SjVi3lGicTteJzhA/ LDeIBdSW9c7aJMM8kKe2PzxIAz/tvZ8= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1660168603; 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=i0a/3GKlBKDqjZOUqm+Ai/MPjy54p3lvrq9RguS53iA=; b=QtaToRYuyJ7B7eTJPbeLLTLDAII4kssW7G2v3KPa1yApBauI6esCvLSzNmLm1o7X+DbgU0 15WDljnpo+2qmLC/MLDIkvvxTb160a7Pt/FoCFzYpqflB0qWDafCZzrl2ueYXg9jB/U+Ep i/woNui0QiONggUitYpSJii4rdK55Ws= X-Rspam-User: Authentication-Results: imf29.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=p0rpGImM; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf29.hostedemail.com: domain of yuzhao@google.com designates 209.85.217.45 as permitted sender) smtp.mailfrom=yuzhao@google.com X-Stat-Signature: fcen6y3o6r7o71ufapfeiuodesfwkmxh X-Rspamd-Server: rspam11 X-Rspamd-Queue-Id: 6DD10120176 X-HE-Tag: 1660168603-264071 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 3:39 PM Alex Zhu (Kernel) wrote: > > > > > On Aug 10, 2022, at 10:54 AM, Yu Zhao wrote: > > > > !-------------------------------------------------------------------| > > This Message Is From an External Sender > > > > |-------------------------------------------------------------------! > > > > On Wed, Aug 10, 2022 at 11:15 AM Alex Zhu (Kernel) wr= ote: > >> > >> > >>> On Aug 10, 2022, at 10:07 AM, Yang Shi wrote: > >>> > >>> On Tue, Aug 9, 2022 at 4:36 PM Yu Zhao wrote: > >>>> > >>>> On Tue, Aug 9, 2022 at 11:16 AM Alex Zhu (Kernel) = wrote: > >>>>> > >>>>> > >>>>>> OK, it is hard to tell what it looks like now. But the THPs on the > >>>>>> deferred split list may be on the "low utilization split" list too= ? > >>>>>> IIUC the major difference is to replace zero-filled subpage to spe= cial > >>>>>> zero page, so you implemented another THP split function to handle= it? > >>>>>> > >>>>>> Anyway the code should answer the most questions. > >>>>> > >>>>> They can indeed end up on both lists. This did have to be handled w= hen > >>>>> implementing the shrinker. > >>>>> > >>>>> We free the zero filled subpages, while modifying the existing spli= t_huge_page() > >>>>> function. Will follow up that change in another patch. > >>>> > >>>> FYI. This series does it: > >>>> > >>>> https://lore.kernel.org/r/20210731063938.1391602-1-yuzhao@google.com= / > >>>> > >>>> And this one: > >>>> > >>>> https://lore.kernel.org/r/1635422215-99394-1-git-send-email-ningzhan= g@linux.alibaba.com/ > >>> > >>> Thanks, Yu. I totally forgot about these series. It is time to refres= h > >>> my memory. > >> > >> I looked through these patches yesterday. There are indeed parts that = are very similar, but the approach > >> taken seems overly complicated compared to what I have written. What= =E2=80=99s the status of work on this since last year? > > > > Overly complicated... which patches and how? > > > > At a minimum, you'd need 1 & 3 from the first series and this patch: > > > > https://lore.kernel.org/r/20220608141432.23258-1-linmiaohe@huawei.com/ > > The changes from the previous patches implement freeing of THPs as part o= f memcgroup and reclaim. Zero tail pages are disposed of via > lruvec as part of reclaim. Which series are you talking about? I listed two series and they are very different on the code level. > Our approach is a thp utilization worker thread scanning through physical= memory adding under utilized THPs to a shrinker that calls split_huge_page= (). We free zero tail pages within split_huge_page(). Reclaim will trigger = the shrinker. > > There is some overlap between the implementations, in particular creating= a linked list in the third tail page and methods to check for zero pages. > (I believe the previous patches have a cleaner method for identifying zer= o pages). However, looking through the code I do believe our approach is si= mpler. > > We chose to free within split_huge_page() The 2nd patch from the first series does exactly this. > but it=E2=80=99s worth discussing whether to free zero pages immediately = 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 patch b= y itself though. Will send that out shortly.