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 bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 4964FC4706C for ; Tue, 16 Jan 2024 13:09:17 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=GKcue1vcmutvipt++qaDjb92UHm2NcckaBGEVb5wLP0=; b=aVHBFFxwbeCoJS kLIK+wJ/N2zaeqtMj+g02cTFpL+oeSzc90sDw7/9CKm18S56aCYQxG2Jgu+U8KAIDaKCQN9eUfwqX Sr4r0Y9PhdtAT+PtVlUCUz1jGQcUyrVH+NPapEXSWQ3/E4jip/nmCcbETJHtkzeiFasqVptNh+vsI vHTX3k+yrvA7tnWcN3LgrRK5Ip/XlKXgrFV6fj3JPwg/61tuaQdBUaTzMfCMdOTgcfunVPCdVTF56 7SpkdtrCrL0eeggn9OoPGt83V0QxGWZEZsko7AEypHaAayMHKUIiweJibB63ceZlrSjSpOwMerRpl MjEnsjIjofbATCti+gTw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1rPjBL-00C8PX-28; Tue, 16 Jan 2024 13:08:43 +0000 Received: from foss.arm.com ([217.140.110.172]) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1rPjBI-00C8ND-2J for linux-arm-kernel@lists.infradead.org; Tue, 16 Jan 2024 13:08:42 +0000 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 386F12F4; Tue, 16 Jan 2024 05:09:21 -0800 (PST) Received: from FVFF77S0Q05N (unknown [10.57.90.186]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 138893F6C4; Tue, 16 Jan 2024 05:08:29 -0800 (PST) Date: Tue, 16 Jan 2024 13:08:20 +0000 From: Mark Rutland To: "Russell King (Oracle)" Cc: "Christoph Lameter (Ampere)" , Anshuman Khandual , linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, Valentin.Schneider@arm.com, Vanshidhar Konda , Jonathan Cameron , Catalin Marinas , Robin Murphy , Dave Kleikamp , Matteo Carlini , akpm@linux-foundation.org, yang@os.amperecomputing.com Subject: Re: [PATCH] ARM64: Dynamically allocate cpumasks and increase supported CPUs to 512 Message-ID: References: <794a1211-630b-3ee5-55a3-c06f10df1490@linux.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240116_050840_900251_31674462 X-CRM114-Status: GOOD ( 15.69 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Mon, Jan 15, 2024 at 03:39:00PM +0000, Russell King (Oracle) wrote: > On Thu, Dec 14, 2023 at 04:05:56PM -0800, Christoph Lameter (Ampere) wrote: > > +# Determines the placement of cpumasks. > > +# > > +# With CPUMASK_OFFSTACK the cpumasks are dynamically allocated. > > +# Useful for machines with lots of core because it avoids increasing > > +# the size of many of the data structures in the kernel. > > +# > > +# If this is off then the cpumasks have a static sizes and are > > +# embedded within data structures. > > +# > > +config CPUMASK_OFFSTACK > > + def_bool y > > + depends on NR_CPUS > 256 > > Should that be ">= 256" ? I don't think that ">= 256" makes sense. Note that since the cpumasks are arrays of unsigned long, they're chunked into groups of 64 bits: 2 to 64 cpus: 1 x unsigned long => 8 bytes 65 to 128 cpus: 2 x unsigned long => 16 bytes 129 to 192 cpus: 3 x unsigned long => 24 bytes 193 to 256 cpus: 4 x unsigned long => 32 bytes 257 to 320 cpus: 5 x unsigned long => 40 bytes ... and so if a mask for 256 CPUs is too big to go in the stack, so is any mask for 193+ CPUs, and so ">= 256" should be clamped down to ">= 193" or "> 192". The boundary should be just after a multiple of 64. How did we choose 256 specifically? I note that x86-64 allows 512 CPUs before requiring CPUMASK_OFFSTACK, and I see that powerpc selects CPUMASK_OFFSTACK when NR_CPUS >= 8192. Mark. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel