Received: by 2002:ab2:620c:0:b0:1ef:ffd0:ce49 with SMTP id o12csp412219lqt; Mon, 18 Mar 2024 11:18:14 -0700 (PDT) X-Forwarded-Encrypted: i=3; AJvYcCVgTcvgbKCcChPwY6UwLyRFv34lMqcRZP58nMrdN1NZ1GKuRRwsMxkREhj642+usHh+9EunaFY7+Pm8v62BT5dEMtlb7EaTcOScWEsmPw== X-Google-Smtp-Source: AGHT+IHqYh2BjivrS2wQadfw2fSvGUt0k1bys1g+9ol0SXROsaCV6sGWSCm7NG/qQBV83c9HNenj X-Received: by 2002:a17:90b:150:b0:29b:bcd5:9556 with SMTP id em16-20020a17090b015000b0029bbcd59556mr10586409pjb.30.1710785894064; Mon, 18 Mar 2024 11:18:14 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1710785894; cv=pass; d=google.com; s=arc-20160816; b=c3ouyaNJuCmspJRYjfB0LAxIjnbCQed8di0nfYMQSqm0M0APACW5ao6VzNn0JSZR5O kaW4w577AhsaM9mNqIhEkwE6axE1lAlD2P+II8DW5OVFsm+WXnYDrLi342V9RqMADEln r1BcsRiqFk11/4+c0ykRk44mMntYaDKtBXZXrTir4HzDHlXdRZowJoOYylEzr3Qwr2pD eZ+/DWHgg9jaOQGM2ZYUuY2gqhjkAEpueufqpwv/HGKU0xt+GJU2X95oy6Ie19xh1sz5 7Hjnbfi/hUyrsqUy7dxRSUXRjqX7z5tbmy31CgIMPhXQkmC3wsglmkqwObBdtfJmEEyO kDeg== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=in-reply-to:content-disposition:mime-version:list-unsubscribe :list-subscribe:list-id:precedence:references:message-id:subject:cc :to:from:date; bh=av9hiBVLJ/Eg4GwDcBmu2simY3K/npbcSPW07rP5Xpw=; fh=60cRSu97UVGhuO2oJpzNMzFXw2GWq2Q4sLplb0hqSSY=; b=QoE2aGByjhVbKT6iTXVhaOcuO6sOYqfZHrJJ4I8IY6TkatzDGPlqI0q8ONuukh0anF 1S+WUKe3inTUlOBqUnx+6NhdnzLEykRfTujlSqn2+LPCJ/jBWt2LfH9eY3F2lge95r6k SSCMujtcQRyXU/I6DerqVBWIZ8CLUYfBplEPlvFY5sbqcmb/cAcmqoJzBFkmnXZ+4bgx KlDydWY2nffpj4j86WNu7/k7q5B+RCo48A7Iun6cJlI+HkklAcyhPX3nqqHz4B7eq9V/ wtdiNklPA3FgIoziQBy9YyDv6ulCQJPqP1yFw1IfB2BLnLemmTLOrlHimKvOMuMR+N+z BI3g==; dara=google.com ARC-Authentication-Results: i=2; mx.google.com; arc=pass (i=1); spf=pass (google.com: domain of linux-kernel+bounces-106505-linux.lists.archive=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) smtp.mailfrom="linux-kernel+bounces-106505-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Return-Path: Received: from sv.mirrors.kernel.org (sv.mirrors.kernel.org. [139.178.88.99]) by mx.google.com with ESMTPS id az7-20020a17090b028700b0029c75618daesi8478446pjb.25.2024.03.18.11.18.13 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 18 Mar 2024 11:18:14 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel+bounces-106505-linux.lists.archive=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) client-ip=139.178.88.99; Authentication-Results: mx.google.com; arc=pass (i=1); spf=pass (google.com: domain of linux-kernel+bounces-106505-linux.lists.archive=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) smtp.mailfrom="linux-kernel+bounces-106505-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by sv.mirrors.kernel.org (Postfix) with ESMTPS id B6CD5283782 for ; Mon, 18 Mar 2024 18:17:56 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id ED1F457334; Mon, 18 Mar 2024 18:17:28 +0000 (UTC) Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 6CF5956B7F for ; Mon, 18 Mar 2024 18:17:28 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1710785848; cv=none; b=azQqX6UTxUdqk+T77snOZbSAnG5zWnj51no0tJ61DaHYWUVW8OgHqWS/0pdZ/meCKzqNfBPE0G/gVptt43O4yjB0CC4ckqtYRoqWSQ6FzxT2x4ziee7utiRB5ym8JM4v3U016bwp7jxv+jfps3c9fZLtH/7yzHgfqIOyzQpCK2g= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1710785848; c=relaxed/simple; bh=wpz+jpXp1/xLYY8u8ro7WOlKUYxshynrXNl0hjCDdXc=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=joO3HKm/v4ryyEzfF63mxgkhDWvsneWj4S3JDGyWyWqsJkHH6Ewh2YVZN8EvFy4TXMznwyqHe9BX5HvPcZaC4lMLpfZfgfJWqZqjg1E7o5p3/8jc845t65MV8jqeFxIdxwEmcTYMPsYezWssLGHYLcD1UTDG3CE/b1d3XSCJgpU= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 Received: by smtp.kernel.org (Postfix) with ESMTPSA id E9D78C433C7; Mon, 18 Mar 2024 18:17:24 +0000 (UTC) Date: Mon, 18 Mar 2024 18:17:22 +0000 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 Message-ID: References: <37099a57-b655-3b3a-56d0-5f7fbd49d7db@gentwo.org> <170983839495.1825460.8461454086733296317.b4-ty@arm.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <170983839495.1825460.8461454086733296317.b4-ty@arm.com> On Thu, Mar 07, 2024 at 07:07:07PM +0000, Catalin Marinas wrote: > 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 I re-instated this patch in arm64 for-next/core as: https://git.kernel.org/arm64/c/3fbd56f0e7c1 -- Catalin