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 63C3AC3064D for ; Wed, 26 Jun 2024 19:38:26 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id C61546B0088; Wed, 26 Jun 2024 15:38:25 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id C107A6B0089; Wed, 26 Jun 2024 15:38:25 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id AFF266B008C; Wed, 26 Jun 2024 15:38:25 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id 8FF5C6B0088 for ; Wed, 26 Jun 2024 15:38:25 -0400 (EDT) Received: from smtpin03.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 44D6FA16EC for ; Wed, 26 Jun 2024 19:38:25 +0000 (UTC) X-FDA: 82274051370.03.FA926E5 Received: from mail-wm1-f44.google.com (mail-wm1-f44.google.com [209.85.128.44]) by imf20.hostedemail.com (Postfix) with ESMTP id 6A84C1C000B for ; Wed, 26 Jun 2024 19:38:23 +0000 (UTC) Authentication-Results: imf20.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=PGxurhoP; spf=pass (imf20.hostedemail.com: domain of kmanaouil.dev@gmail.com designates 209.85.128.44 as permitted sender) smtp.mailfrom=kmanaouil.dev@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1719430687; 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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=m4EfN9g+uqlLGrFo+op5g1mK7c56SzK+pHDgUEe5bzM=; b=ga3SzwIRlpDwP+nHnQ4Z6NSqobzzVu1nJgjReZF1oiL3Y7vQRIZXtrAsjweSWe991f3lr6 3QW5f590aOpGlS/TDjlQ36+Z5sOjuTg5WfNHsubeWQQz32g8zRUt4v77F+TRQYMOz4lxs7 bN7uAJJuqf1c5inT1pQ62ng9vDhMkM0= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1719430687; a=rsa-sha256; cv=none; b=GdX9XuEO8c3Ml/1CYhulD0684sX8+WALM2y6UzQodsDe/vpFwm0+Bo+GRaKMUu8yOL0kGo DjD7TV+hExHZZUb+itI8MRaigkDUbtKgvt0yu3YhCJo2Hnm16gfRDfK+Wlz5vM2FHM8Uwl C9Ax03zSbJG6xD8FDX2sLSTCPb9vgkA= ARC-Authentication-Results: i=1; imf20.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=PGxurhoP; spf=pass (imf20.hostedemail.com: domain of kmanaouil.dev@gmail.com designates 209.85.128.44 as permitted sender) smtp.mailfrom=kmanaouil.dev@gmail.com; dmarc=pass (policy=none) header.from=gmail.com Received: by mail-wm1-f44.google.com with SMTP id 5b1f17b1804b1-4212b102935so6695995e9.2 for ; Wed, 26 Jun 2024 12:38:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1719430702; x=1720035502; darn=kvack.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=m4EfN9g+uqlLGrFo+op5g1mK7c56SzK+pHDgUEe5bzM=; b=PGxurhoPzKhPqxmwpJD0NuC2QSAlgzGU3zGwaANLUrjE3w3DY7oI1SyZgGi57KG5fx fWMONe/57vOLa/Ef5k6shCS8NUw/ayCTiZmOf1PuZ/d362hIQWkM5VTWDgGJqjH8disz cxQKTV8Jz3HOX/dYGog6raO/2n0qkhWyZtf6jIsg/ELi+jUKT4fg8A6aFufxMjpLlBTW EU2Pnfvi/WNhWTDQc1Ybh/98EP6YmGPRCt6CPIe5/al3+OUVWdKuEQUX6ysy+Og0Tqba ikbGFoDESNCLSXkEc2zvLSgQCqNgm5FYGQJMoWnUkoe0a+upvm4LzrZr1HaLd2hKjKYC soZg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1719430702; x=1720035502; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=m4EfN9g+uqlLGrFo+op5g1mK7c56SzK+pHDgUEe5bzM=; b=pLWTBySAfbkur3UKElz+BfsXbKB0mcqkBcHyYgmbwH1uqanti435haoyWLbW5W8QNi L5MxBFh8ZwKL7Q8ze3o+LMZ62HKrXkKbWMusZ8htb2Y+Pb3phwm5ER4Z30rWJ97NpTLb xKBiVhILiUKse7y7QkiLTabyTnRBNAwNKxePNAbGYJrAXl3kk3mBeegr99sCm/tjHnyi H2ppGNkmoken1dWwaMKTMiUlc3tyAFCigEfkwQBnIMMuwnjnzZhansqH0UQBnzctCivr 93YTbQP9ZfMhZdW9ebEeGlnYqou2seVkTsPOciZ4LrORcV9jzvtAktLQoEs5Vtpyrcmf zugA== X-Forwarded-Encrypted: i=1; AJvYcCUsKWquxgTALX4FPX84ZjYxp64GaI3zrSOC74vzpUEc2qXDfiKEou/WxThb3JcM7Q17FJkcwBzy3gLkVbV/Y7UQATM= X-Gm-Message-State: AOJu0Yzf2+XckJ0reHARdsV3uNny2GKbOEymxOwahMKLCIYA3ZdtRBn8 V45qRG8ccnVjikLuq7tKtWvp7E2xkX1OHpsdHbqhlx1TAPZSPx5J X-Google-Smtp-Source: AGHT+IE8Vy+DRmlqBj9zfSwRcPREE9mj88AQhyU8cI/31aCnYOPOe4xeJ7EByxwKOgC/fnGMUKqFkg== X-Received: by 2002:a5d:5983:0:b0:35f:2929:8460 with SMTP id ffacd0b85a97d-366dfa2d903mr10705059f8f.3.1719430701738; Wed, 26 Jun 2024 12:38:21 -0700 (PDT) Received: from ed.ac.uk ([2001:630:3c1:90:1614:6de0:61c7:40b0]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-3673cfb48ffsm416393f8f.3.2024.06.26.12.38.21 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 26 Jun 2024 12:38:21 -0700 (PDT) Date: Wed, 26 Jun 2024 20:38:19 +0100 From: Karim Manaouil To: Matthew Wilcox Cc: Yafang Shao , David Rientjes , Andrew Morton , "Liam R. Howlett" , Suren Baghdasaryan , Christoph Lameter , "Paul E. McKenney" , Tejun Heo , Johannes Weiner , Davidlohr Bueso , Namhyung Kim , linux-mm@kvack.org Subject: Re: MM global locks as core counts quadruple Message-ID: References: <07e7d078-0c9d-6a1f-1ab5-295f86974b72@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Stat-Signature: 514w61gd7pts9psetxdbrxhj3j7oa67m X-Rspamd-Queue-Id: 6A84C1C000B X-Rspam-User: X-Rspamd-Server: rspam08 X-HE-Tag: 1719430703-778713 X-HE-Meta: U2FsdGVkX1/YzEqDp342Q7g07WUAJ8eEKPb8V+/oJvZI+d0HKjv7czYk8kVI5CamVr8o8+NiE8Ui7V7mIu26DtqX0YLwyrfhru9VyO3BY0ENccmnrlDG91ukJ33C05dRV0Pbv5rmSpSTdMGLSbcFUTeXp0Z1TXy3SQjjdUM2Q+KMh0kbleQZiEWFTD4LDcF21GBGU6jjTRpA345vlryEOPLEgsivypRXLGGXaNR7WfJtPfBVmUxgm5J/ALpKUWQb8L7Jnz/Nb1J1FUEC+i5iYSwUaWfIHdp/NNeFe4t0vDlsyd1RF8dF+39hxYDN8CNfxqu/vKTf122zroHN4XuohMjtMmy2rjClUQKl1Fcl9N8IMyNb4rbBelE7rtvBrbfzAl7FJ83l0Ftt9fW+0SKqodOisKQ9Av9xmVyZWBXvqVnjY0YI1BSlw58Q7Lp67ZQE0WWq5eW7/00jhnwZPjbk2tz5JiF3OXBXN9imumnJHXY2AJ1bBGlM/wuK10vR5FkcwdnbUOrR/0j1Aa1P5VeV0OaiG/5iv3CmPwZIQYzp5jr0LtntuCYYm/Z5ET8UWLqulwkdzpX2Qd89rkUVfqH6pU+h91to5nLFJ6ODeJL3aZBdS7NuPV86yk3mk6CyxlnQuf9a4wzKdYiBY9eerSm8mvOwtqMaZPK/DO5jIGMwwuMCB48jYp5xZXfojtQruLOyzfUBNw2J520viqRJ4bqNJCvsJ/kXmZsO8tsJcwEO3yT8ZCxVo9Bq+4lvjkDbnSvirsQmu3B9OLzfdndrNAfyxY3KN2IgAKg0zDb9mt5GW6SDQqTMGcOMYkNyf2tJu0pLcWXeLC2YMC5kzEaDmjZDERj8iI+8kvK005aAnQRUDRiTDyXTpXhghE/Px01SwYA36qkcjiQyQXByejVEnqdCLSjD/cmUeFNWZeJozsG1cdjUFT2M5qiSR95bqrik6XXJtD9BJAQXWcznY8ImoRx iWkkfu0q hdjLbA5cSoInEL1CtY6pww49hPMcjlAYXWY8NbZgWCOT/hAExIeFwSYXhIhN3YrOP5QgpZedCxjXqqb4/Kl9dDNEuyr4hIbxGES3+waS4RIyrdwvJZN8wGooKkckUhU/Wm5Rf7pE9ulZwPYIwSwYYIT89sghuTjXcHvviCT7f027nDuHGG1ywGmtjB/f9RR0ECcxLOWfB1CYizCrrjfale6+PUCimfrglt3XM0nFg1FHwHHD8NdfXfO9WPlbKXzJH8zKKCyCvElLpH5nj3nKom7JGdRxqeB0pR8C9m/uogWbk9X0e66+b5rV5PjmJdBfyXrgTO/HeTpIOxeixHj+aknXBTYmsv+edZzM9GqUMNqT82rO9+MMqJ/Sd2VDyA+zVef6N9zQzcsSwt9Y5l1G+EwT0jygINh3mzZOobyqpld/rX3t9RDCFNr7HQr3KgpH80Y+z9IWtfh4AVsBp1U69rWXoxWri1uE2iD9AS0eZSL6ycCwljvgfFu6S0Bp5oGtt5PJe2HEBRhoewEzDjwUTWFjCbWHyR+14orE3srxgavp/qyHn1C/tb65g4eOZlI4diMjtHg4P2/7+k3ywZiLxxwNax/8iW1ZN8yWX X-Bogosity: Ham, tests=bogofilter, spamicity=0.000008, 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 Fri, Jun 21, 2024 at 03:54:31AM +0100, Matthew Wilcox wrote: > I think a more productive solution to contention on the LRU lock is to > increase the number of zones. I don't think it's helpful to have a > 1TB zone of memory. Maybe we should limit each zone to 16GB or so. > That means we'd need to increase the number of zones we support, but > I think that's doable. What do you mean by zones? The usual ZONE_{DMA|DMA32|NORMAL|HIGHMEM}? But that's historically existed to deal with physical addressing limitations (e.g. DMA for devices that can't deal with addresses larger than 16MiB, or HIGHMEM on 32-bits to access physical memory beyond what could be directly mapped by the kernel). Maybe you mean turning ZONE_NORMAL into an array with each entry pointing to a smaller ZONE_NORMAL region of, let's say, 64GiB or smthng. Or it could be divided by the number of CPUs within the NUMA node and each CPU will be given one ZONE_NORMAL segment with a fallback list to other CPUs segments in case it runs out of memory. Does that make sense? Cheers Karim PhD Student Edinburgh University