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 14D75C47422 for ; Mon, 29 Jan 2024 06:23:22 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id A3A9F6B007D; Mon, 29 Jan 2024 01:23:21 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 9EA876B007E; Mon, 29 Jan 2024 01:23:21 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 8D9B06B0080; Mon, 29 Jan 2024 01:23:21 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 7D6F26B007D for ; Mon, 29 Jan 2024 01:23:21 -0500 (EST) Received: from smtpin12.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 52A1F1201D4 for ; Mon, 29 Jan 2024 06:23:21 +0000 (UTC) X-FDA: 81731356602.12.14BFFF7 Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) by imf25.hostedemail.com (Postfix) with ESMTP id 81ACAA000C for ; Mon, 29 Jan 2024 06:23:17 +0000 (UTC) Authentication-Results: imf25.hostedemail.com; dkim=none; spf=pass (imf25.hostedemail.com: domain of artem.kuzin@huawei.com designates 185.176.79.56 as permitted sender) smtp.mailfrom=artem.kuzin@huawei.com; dmarc=pass (policy=quarantine) header.from=huawei.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1706509399; 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; bh=ZfVwW/uYyrv9Tb92ZXSPKKEkBj6TBgafbGbGZJ6QkGE=; b=sZ1JpGTzqyQKmJgJ8ke8FOTB/J6Ez4T4wOifzre9kbwFXd2dgXB+8MT4cQAHfY3Ei1n+1B c+xpi2HvxDhHeZOBNDCM1X+utHmF8c14E+TGuM/IShks4BEVCF/dyswc2vFgOMwO2JnzUN BbJ1mBN/FU1v4voagTrE5wOG5NlNgwo= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1706509399; a=rsa-sha256; cv=none; b=1zTe9PrpglA4NchJTzeadfFHNJpxq8zg4mU/AluZrlt1inTLRtR920TJvPSTwH9h77VvIq N06HnGHPkLscDEHXVTS8RWEG9HsxT18fhgG3qGzP9Vgo5sJsER/ub0ywAZyNvfgR3GcDyj Z/rxfxl5H+hgBT374DCSt6xELSUu9L8= ARC-Authentication-Results: i=1; imf25.hostedemail.com; dkim=none; spf=pass (imf25.hostedemail.com: domain of artem.kuzin@huawei.com designates 185.176.79.56 as permitted sender) smtp.mailfrom=artem.kuzin@huawei.com; dmarc=pass (policy=quarantine) header.from=huawei.com Received: from mail.maildlp.com (unknown [172.18.186.231]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4TNdT34nFHz67pY8; Mon, 29 Jan 2024 14:20:23 +0800 (CST) Received: from lhrpeml500001.china.huawei.com (unknown [7.191.163.213]) by mail.maildlp.com (Postfix) with ESMTPS id 9DDF7140B55; Mon, 29 Jan 2024 14:23:12 +0800 (CST) Received: from [10.123.123.147] (10.123.123.147) by lhrpeml500001.china.huawei.com (7.191.163.213) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.35; Mon, 29 Jan 2024 06:23:10 +0000 Message-ID: <5a7485f8-a070-465d-9e17-e7cd3d2aaa80@huawei.com> Date: Mon, 29 Jan 2024 09:22:59 +0300 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird From: Artem Kuzin Subject: Re: [PATCH RFC 02/12] mm: add config option and per-NUMA node VMS support To: Dave Hansen , "Christoph Lameter (Ampere)" CC: , , , , , , , , , , , , , , , , , , , , , , , , References: <20231228131056.602411-1-artem.kuzin@huawei.com> <20231228131056.602411-3-artem.kuzin@huawei.com> <059dc132-af10-fd08-7368-302c765a4269@gentwo.org> <6c5c72ab-01b1-45b4-9a33-529688e449eb@intel.com> Content-Language: en-US In-Reply-To: <6c5c72ab-01b1-45b4-9a33-529688e449eb@intel.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Originating-IP: [10.123.123.147] X-ClientProxiedBy: mscpeml100004.china.huawei.com (7.188.51.133) To lhrpeml500001.china.huawei.com (7.191.163.213) X-Rspamd-Queue-Id: 81ACAA000C X-Rspam-User: X-Stat-Signature: tw9f9ays8n1wys6yt3yys8kha6dw5zc8 X-Rspamd-Server: rspam03 X-HE-Tag: 1706509397-501384 X-HE-Meta: U2FsdGVkX1+pwfL/l/2cQBLsGPz4Jhoau3bueARFv0v8yh+laNLz8Lr5pat3VR++FBkpujGxLWw47nrHG+AJpuX/njxXEbx3Tah5OWkx7PrbPIQNoT3nJOJr3Ol7K/HNYBzFlAFGvRILkghP7Cim94hrf/2Zbv0pmdomLnhKz461rnc6m2giHyQfRvZNpo2YF8gA3lLI84IsXzTM+z7YROsimoWqkt53aC6nzGn8IRt4XDhN3ODcLHIY4ZaiV5+IGApqPLgauvRbTFxvrPdQC4RcekX4WSTbVjb3n3iKoqkzIM81tB2SPwrhgpw/ZRZ5jbdQt+4hi5IN60PAJnXIzceqslYxOhvvVrh+i7LsK0X4z0q+2AIneq0Rm8fLyz9vlkXApvWjbfEtXBg3SMkR+kuPVBas1BPJWLTngi+PpvpsDPNlK50gQSWyKCfqvmVgYPG3wh2WWjYnsslzaJaIGU3GUCNVQhp7NK2JX6Oh+41BNbCnBQGekthV8r9OS1KYWaN6jJeWrlvkbUBUG6tCzuNqd0kCYbVvVzefBIzZiPoHgZca63na+1SRO8R6/tjw9MPUDzfe1RZnH6d3eGJh3CNHMC0NFzhNL1LxrTRXfFNpI0qeP2sLtj+tDe5uO0ojiSkXY2fwrxFS4S3RuEPIdN/tA+uKKmeg4AQe8oWcI+Isb451d0wYQWowsY6mA7TRl5aJaZV6aUxL7TH5/4/n85OcFXFQsSAU9haFHwPKNzz6MLwJTvREDlKUfCu2I5I8SyziJxSd8XWaoyjpoJsBneyHoLCSwNNiqj7+WMdN4qep9D6mA2Bl/MKffGK1wu8ri4TnZYWAvULnl9TFlcBL3IHHufMfGNmoHMnLuIjw673zVD72EmRRmXkWUzUQ8i/e43OxM8aQ/HiYGg3Zz/XKIm/ccJbkPy9jOhf06LTUDQRMG3pzh7skVM/mBZjugahoQ3ysi6LLJP2t32M483I m8tE/oby TekQpzWq3Yt0hbUq7+Rk3epYvVZPPC4DvEfjuPmxGNwweQRy0X2tqh0qO+1H7XsNE4QXxBMZH6WzErxvgRWQTVEuPtLulBKXVT4p7NaGvFb/Ei1sfe5SGzS4Wxu2xyMUrcZvFVUgbt0OIMi2A5I9cO1w4O98alrQMm6ALwbW6ApHezWkwon5ILlR8wN1iYc0LqGRUYQix9aj0aOyeY30BU5/cdAi7Te9OhLy2hr3iTG6m+ZM8PMFQXX96Hw== 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: List-Subscribe: List-Unsubscribe: On 1/25/2024 6:07 PM, Dave Hansen wrote: > On 1/9/24 08:57, Artem Kuzin wrote: >> We already have per-NUMA node init_mm, but this is not enough. >> We need this array of pointers in the task struct due to the proper pgd >> (per-NUMA node) should be used for threads of process that occupy more >> than one NUMA node. > Let me repeat what Christoph said in a bit more forceful way. > > MAX_NUMNODES can be 1024. You're adding 1023*8 bytes of overhead for > each process ... everywhere, including on my single node laptop. That's > completely unacceptable. You need to find another way to do this. > > I'd suggest just ignoring the problem for now. Do multi-node processes > with a later optimization. Hi Dave, thanks to you and Christoph for the comments. I've just gave some details why this is necessary, and didn't want to push the solution with MAX_NUMNODES forward, this is temporarily thing and this place should be definitely updated in future. As for possible options, for now I am thinking about two: 1. additional config option to limit the number of page tables and corresponding replicas 2. setup per-NUMA node page tables and replicas in a lazy way allocating them on demand But here I need to try and test everything. Thanks!