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,HEADER_FROM_DIFFERENT_DOMAINS,HTML_MESSAGE, 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 AC774C433B4 for ; Sun, 2 May 2021 21:45:44 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 126C061176 for ; Sun, 2 May 2021 21:45:43 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 126C061176 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=xanmod.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 556516B0036; Sun, 2 May 2021 17:45:43 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 539FE6B006E; Sun, 2 May 2021 17:45:43 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 41C2F6B0070; Sun, 2 May 2021 17:45:43 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0147.hostedemail.com [216.40.44.147]) by kanga.kvack.org (Postfix) with ESMTP id 26F5A6B0036 for ; Sun, 2 May 2021 17:45:43 -0400 (EDT) Received: from smtpin22.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id D6C413628 for ; Sun, 2 May 2021 21:45:42 +0000 (UTC) X-FDA: 78097623324.22.D818D35 Received: from sender4-of-o53.zoho.com (sender4-of-o53.zoho.com [136.143.188.53]) by imf12.hostedemail.com (Postfix) with ESMTP id 9FBA0F4 for ; Sun, 2 May 2021 21:45:29 +0000 (UTC) ARC-Seal: i=1; a=rsa-sha256; t=1619991934; cv=none; d=zohomail.com; s=zohoarc; b=cLbSM5C6gmKOoVKKJyRnKyI/j0/tmIn+i81BwZdPNB0Rf0JupXrROTSiDdgEtwtENynd6MUYhKTog1S/7su1Ruh/kej9WEjjiqCA8wEg+akDTd1OVWWbedOoWpKhUFoTS1GHGhMmye7i4hYGOanXhHz7CPAye5wk2xas1zpD3g8= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1619991934; h=Content-Type:Cc:Date:From:In-Reply-To:MIME-Version:Message-ID:References:Subject:To; bh=BbhtqCkPzQ9FlYhVrqHQTmhizmxjpKtnvsoIy9YmU1E=; b=MlAn0S178ypTV+xQYjv/+33b2WoJs/3c0id6IIIYPl3f4jYyQa6WwzRDZ5fTJPvNo65Oc2qdyWVgMzzI7iHmAoZ4xJq1CxUz/cBC3+AT3cHZUVyGAqMXXaz0BIF+wmWIfPKYeIIJ7d/Eu03sLie5eDG5+RQz5vMtRr+c1ar2oCg= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=pass header.i=xanmod.org; spf=pass smtp.mailfrom=kernel@xanmod.org; dmarc=pass header.from= header.from= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1619991934; s=main; d=xanmod.org; i=kernel@xanmod.org; h=Date:From:To:Cc:Message-Id:In-Reply-To:References:Subject:MIME-Version:Content-Type; bh=BbhtqCkPzQ9FlYhVrqHQTmhizmxjpKtnvsoIy9YmU1E=; b=iCLS57G9FOjRAEVaXshp4pmbUPa2K83pdL7JeJ7z62zsSed6KmpD9uhfuB/EkG4b cUHy13SDJ1NOgqgcEift44a2MFcKwPpNyxUaqO78p+6uG4W07veHTE1o4yeyqa4UDub zaww6cNizn0ZBn1ZtHAGtqb5R0m1hMNbdbjW9BO8= Received: from mail.zoho.com by mx.zohomail.com with SMTP id 1619991932478368.8298269518666; Sun, 2 May 2021 14:45:32 -0700 (PDT) Date: Sun, 02 May 2021 18:45:32 -0300 From: Alexandre Frade To: "Yu Zhao" Cc: "linux-mm" , "Kernel Page Reclaim v2" Message-Id: <1792f0b2e29.d72f70c9807100.8179330337708563324@xanmod.org> In-Reply-To: References: <1792aea71ee.e2062a5f778082.9048268443626031415@xanmod.org> Subject: Re: LRU_GEN v2 & v5.12 build issue MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_2624093_649502467.1619991932457" Importance: Medium User-Agent: Zoho Mail X-Mailer: Zoho Mail Authentication-Results: imf12.hostedemail.com; dkim=pass header.d=xanmod.org header.s=main header.b=iCLS57G9; dmarc=none; spf=pass (imf12.hostedemail.com: domain of kernel@xanmod.org designates 136.143.188.53 as permitted sender) smtp.mailfrom=kernel@xanmod.org X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: 9FBA0F4 X-Stat-Signature: 6zpa5ko434u89c3utncowh7dapi4op8u Received-SPF: none (xanmod.org>: No applicable sender policy available) receiver=imf12; identity=mailfrom; envelope-from=""; helo=sender4-of-o53.zoho.com; client-ip=136.143.188.53 X-HE-DKIM-Result: pass/pass X-HE-Tag: 1619991929-581424 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: ------=_Part_2624093_649502467.1619991932457 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Yu Zhao CONFIG_MAXSMP=3Dn worked! The main distros are with CONFIG_MAXSMP=3Dy. It may not make sense on deskt= ops, even for an amd threadripper, but in datacenter / HPC, for example, it= is interesting to add maxsmp compatibility that virtually removes the n cp= us limit. Thanks, Alexandre Frade ---- Ativado S=C3=A1b, 01 mai 2021 23:45:11 -0300 Yu Zhao escreveu ---- On Sat, May 1, 2021 at 8:39 PM Yu Zhao wrote:=20 >=20 > On Sat, May 1, 2021 at 8:31 PM Alexandre Frade = wrote:=20 > >=20 > > Dear Yu Zhao,=20 > >=20 > > I don't know if it's a known issue with the 5.12 kernel released [9f4ad= 9e]:=20 > >=20 > > LRU_GEN v2 & v5.12 final:=20 >=20 > Hi Alexandre,=20 >=20 > I think I hit this problem with Ubuntu too. Does your config include=20 > the following?=20 > CONFIG_MAXSMP=3Dy=20 > CONFIG_NODES_SHIFT=3D10=20 > CONFIG_NR_CPUS=3D8192=20 > If so, then it's the same problem: there are no spare bits left in=20 > page->flags. Disabling=20 > CONFIG_MAXSMP should fix it, unless you really want to use 8192 CPUs=20 > and 1024 NUMA nodes :)=20 >=20 > Please let me know. Thanks!=20 =20 Sorry I forgot to clarify that this option should be disabled=20 regardless whether you want to use the multigenerational lru or not.=20 =20 This option is for debugging and will bring unnecessary memory=20 overhead to production systems. ------=_Part_2624093_649502467.1619991932457 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =
=
Hi Yu Zhao

CONFIG_MAXSMP=3Dn worked!
<= /div>

The main distros are with CONFIG_MAXSMP=3Dy. It ma= y not make sense on desktops, even for an amd threadripper, but in datacent= er / HPC, for example, it is interesting to add maxsmp compatibility that v= irtually removes the n cpus limit.

Thanks,
=
Alexandre Frade
=




---- Ativado S=C3=A1b, 01 mai 2021 23:45:11 -0300 Yu Zhao <= ;yuzhao@google.com> escreveu ----

On Sat, May 1, 2021 at 8:39 PM Yu Zhao <yuzhao@google.com> wrote: =
>
> On Sat, May 1, 2021 at 8:31 PM Alexandre Frade <kernel@xanmod.org> = wrote:
> >
> > Dear Yu Zhao,
> >
> >= ; I don't know if it's a known issue with the 5.12 kernel released [9f4ad9e= ]:
> >
> > LRU_GEN v2 & v5.12 final:
>
&= gt; Hi Alexandre,
>
> I think I hit this problem with Ubuntu = too. Does your config include
> the following?
> CONFIG_MAX= SMP=3Dy
> CONFIG_NODES_SHIFT=3D10
> CONFIG_NR_CPUS=3D8192=
> If so, then it's the same problem: there are no spare bits left i= n
> page->flags. Disabling
> CONFIG_MAXSMP should fix it, = unless you really want to use 8192 CPUs
> and 1024 NUMA nodes :) >
> Please let me know. Thanks!

Sorry I forgot to clari= fy that this option should be disabled
regardless whether you want to u= se the multigenerational lru or not.

This option is for debugging = and will bring unnecessary memory
overhead to production systems.
<= /div>


------=_Part_2624093_649502467.1619991932457--