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 3B477C54798 for ; Thu, 7 Mar 2024 19:07:18 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id BA3586B0278; Thu, 7 Mar 2024 14:07:17 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id B53096B027A; Thu, 7 Mar 2024 14:07:17 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A1CCA6B027B; Thu, 7 Mar 2024 14:07:17 -0500 (EST) 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 8F9B96B0278 for ; Thu, 7 Mar 2024 14:07:17 -0500 (EST) Received: from smtpin26.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 2DF744122C for ; Thu, 7 Mar 2024 19:07:17 +0000 (UTC) X-FDA: 81871176114.26.BF6C8CF Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf26.hostedemail.com (Postfix) with ESMTP id CB32214001C for ; Thu, 7 Mar 2024 19:07:13 +0000 (UTC) Authentication-Results: imf26.hostedemail.com; dkim=none; dmarc=fail reason="SPF not aligned (relaxed), No valid DKIM" header.from=arm.com (policy=none); spf=pass (imf26.hostedemail.com: domain of cmarinas@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=cmarinas@kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1709838434; 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=fydQVkF0garfV4Gf9sE7CtobZYinyD+u+y9FOzLDfy8=; b=pAyt+ilf98z5k77kIWPPoc0oviXwJxjxC3M9Wbzn+DH1zDyeinMN5XXgLrEF1LmwSlojgy bd0ouL2L1rre/fBZUX0apP5VExyXGxVORIo0q3bD6oHMrxKDlVs2Nvc7FfcDztWeuJ/nce sV3yOlMGSLPm6iePNxUGKOjwHLKXz/8= ARC-Authentication-Results: i=1; imf26.hostedemail.com; dkim=none; dmarc=fail reason="SPF not aligned (relaxed), No valid DKIM" header.from=arm.com (policy=none); spf=pass (imf26.hostedemail.com: domain of cmarinas@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=cmarinas@kernel.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1709838434; a=rsa-sha256; cv=none; b=D63H49AR5PQPziOYVtxOdkquot3N9GeBjcomew4QdWu3zVVx2Vwhjjgk+fGRZskqKviZuU ZwguUZVMJsZAW8cIYYxk5OvwdzlI4nvVhpRAyR0ngk+x0dFxxBOPqjb463poG541tZ6hbL YdivI0VAsRzn8toawZ4SqdD7cgL0708= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id 486C861CC6; Thu, 7 Mar 2024 19:07:13 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 84DB9C43390; Thu, 7 Mar 2024 19:07:09 +0000 (UTC) From: Catalin Marinas To: Mark Rutland , "Christoph Lameter (Ampere)" Cc: Will Deacon , Jonathan.Cameron@huawei.com, Matteo.Carlini@arm.com, akpm@linux-foundation.org, anshuman.khandual@arm.com, Eric Mackay , dave.kleikamp@oracle.com, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, linux@armlinux.org.uk, robin.murphy@arm.com, vanshikonda@os.amperecomputing.com, yang@os.amperecomputing.com, Valentin Schneider Subject: Re: [PATCH v3] ARM64: Dynamically allocate cpumasks and increase supported CPUs to 512 Date: Thu, 7 Mar 2024 19:07:07 +0000 Message-Id: <170983839495.1825460.8461454086733296317.b4-ty@arm.com> X-Mailer: git-send-email 2.39.2 In-Reply-To: <37099a57-b655-3b3a-56d0-5f7fbd49d7db@gentwo.org> References: <37099a57-b655-3b3a-56d0-5f7fbd49d7db@gentwo.org> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: CB32214001C X-Rspam-User: X-Rspamd-Server: rspam05 X-Stat-Signature: g9m4y1h8kyedqsh43bj4ymehefaj5wwr X-HE-Tag: 1709838433-87071 X-HE-Meta: U2FsdGVkX18yy4Ik+cLvoxpf2ZMFMzJ9OmcOhlGBGDFVy7XrZ3oPtK+QololPGdikmS3p9aGyH55jhvKvfLkO4NgxfFHitWXnwO8dZUpm+gtoO4ZVhQ52yR2BNSbWP3od1C3rFpE1N+Gb4/0oW4I3WDQ35AfCJlGXvlWH+5VHU3L0ibSdj3l0inwu7sfzHHgvIk6Cz2KTwIsqLNqjqb2L4oVvkHDzQQpGxs6rRHDCbzkfhIleDrE4yog76AstcaZHH+HBatShJ0Q7oWrqWZR9nMVRqWflLsFsrS957FKpWrckfDsmKB4TYd24tUL+K6iWpcwdomxumDBrCbzZ03ArOuvgxsz1FY1YIbRCNwjmDAKrk2gPnAIXWkxDc2Y3x8zR0XFspTTMCV7kf9SAXFvVQPxjwH3z9VLVbBOyW5QdwgoBm+oSCV/4I+iFh4pd99ao7BWzchE/BTUNzhKFiGHDHApZMQQRUVPEx0kQzHIBPCDH/MQWabLRM60e9D+S2PvOMclewwIBCLCBqsQVfzjq8xeb0X51eq5ie4+cuoQwTYLcxU4RHMm2iwWT+sYXMjeC0gvtshucjZZ9l9pdCDhn0gUsbDC4QYUwOI4Pd3Nj7FsNqQg+QhsDcP1Q2dEnkh0VD9y/dFGDCNOOVO3Oylf3LVv5tXUEhjucntAGneNxCfrxmjK/CTBZzjig7XkRWuxamhuJEx69NhmXbAgp5ado2TJv+7G+7YJz7OuSCx0Hxrum3ikkLRgvU0AQjDD7QGi9cbOD4yHAc4nlN1QMO6FgsW5onupssQT3G5tZdsKwDJrs56Hg1cvVUlY6gqjQSa4pLS19eWAcj6w+8kF6svuwQtpxxm5dJRVn4vXjo2+cfZ4hCUAVV0lJzhUP6P0NUqsdidC7wgGngZ5069N9qlrelT489ok+iEYCLPlV1+qKkdWQT1L88YR8NsZkX+F/mCYjur6wOTtgQdkWX6w72Q RXS60dj8 WWaILDWzaRtR9/Fk/sYIjuT3iYnuxbj2pGvB2hQTKShsUEQ2HRaTFjx6qpqM1IOHmbrzo95Qcao+dId3T22mwVNxku6vPAyXzV3lD/kz4p4FeQuy9HQYNK2dTIwsK2W/FHJMXaH4YIXX7lxV7VQ+4VX7bB6B4tRwgOLZJmP5agKJV9EE6DpkJK04Wouk6yB23W2sbJqm+3ccqUclNnJhZRKbBmeku2RPF03oDCySial5a82KI+ed6aIFC/c3uihjs9tIiaimVaJ1BNomktYa8MmxyZ/q6RPaxaUD5XyIBhY1X+2UgVeIvwudUv5rxmtB4d8XP6wZj2waZhmkSwzweyIeg4MduP+bgKC8891La3Z+0T+EHGKyj9bn5L8rsi0U9m6uCWuJRf2YnsW1V14QHVHqyCQU8RqyE16p5 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 Wed, 06 Mar 2024 17:45:04 -0800, Christoph Lameter (Ampere) wrote: > Currently defconfig selects NR_CPUS=256, but some vendors (e.g. Ampere > Computing) are planning to ship systems with 512 CPUs. So that all CPUs on > these systems can be used with defconfig, we'd like to bump NR_CPUS to 512. > Therefore this patch increases the default NR_CPUS from 256 to 512. > > As increasing NR_CPUS will increase the size of cpumasks, there's a fear that > this might have a significant impact on stack usage due to code which places > cpumasks on the stack. To mitigate that concern, we can select > CPUMASK_OFFSTACK. As that doesn't seem to be a problem today with > NR_CPUS=256, we only select this when NR_CPUS > 256. > > [...] Applied to arm64 (for-next/misc), thanks! I dropped the config entry and comment, replaced it with a select as per Mark's suggestion. [1/1] ARM64: Dynamically allocate cpumasks and increase supported CPUs to 512 https://git.kernel.org/arm64/c/0499a78369ad -- Catalin