Received: by 2002:a05:6a10:6744:0:0:0:0 with SMTP id w4csp1152050pxu;
        Sat, 24 Oct 2020 02:05:02 -0700 (PDT)
X-Google-Smtp-Source: ABdhPJwu8DZfozQPYjFCPAJlEDcUqlogUQMSxOnKRnFx8gAGQ5Tv8b34O386RVx0TMvzadm6uGP8
X-Received: by 2002:aa7:cd98:: with SMTP id x24mr6085257edv.237.1603530302049;
        Sat, 24 Oct 2020 02:05:02 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; t=1603530302; cv=none;
        d=google.com; s=arc-20160816;
        b=TNwuTNHzzgo7SCvfclJvJDI7x1DB3mMVQvDzH42tOSyng9bPeR/B2WGoTZBoO9gybk
         Fw/RFvq5etG+TK9itVqRREiv5UdsSTuBBFvbHkqvZdxlXqWkwOAsCWoRszL4FghucplN
         2TKIQwzD/Qff9AE9DZpoEl6gVyPgsBkllloqTLPZ6aMfKz9OwJbuPwsd2tsr+D08DzCa
         +L8jFVPq55vXNCU4GG2+DMXcv6lMmSKpdNZE/P7QnVUj5j2NZFg2A2qsoczwpihY4LXR
         frsbPH/BiA8t8bnWvN9wdOdSSt5UIbdRH5Bt/RokYMHwyuus5N8IvdY4RY2ag4DQwNKQ
         Q7Og==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816;
        h=list-id:precedence:mime-version:message-id:date:references
         :in-reply-to:subject:cc:to:dkim-signature:dkim-signature:from;
        bh=mcqtPkA0tz7ylkWcpgHi1whok+ruukbSXl7bVbRNeHw=;
        b=qG2Dx/5rYPuEiWXDmtjpgdMi70zSuhudy4OzTRKyKpslD7jRw97XQRgeJioRj3Edux
         butLxs+dj3Mvsa+9c6+1FxVZtggDSWCzeJQDA9x5W5oQ84tN3EDGEV8MxHhvs1887C72
         HANV3FIPJiupg4dhuvtoAf9B9ClimfB3FDMFoxSnSR9IxCiScv8dBQU/HIvkwB5oj+8T
         FYaVZs1vZ+cYovaeEejWqZ3xu/zgzk4uXVsvMkV5lHiiM3oiHNf4uEO/O7mMTDHMDt0S
         6PEQiFlxR+WcarffEDI4HT0lURTAx7aFn9MQA7SqiUvIOw2NQMfMOfoYfDyV4uK9vGYU
         zoTg==
ARC-Authentication-Results: i=1; mx.google.com;
       dkim=pass header.i=@linutronix.de header.s=2020 header.b=FpQmBJoq;
       dkim=neutral (no key) header.i=@linutronix.de header.s=2020e;
       spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org;
       dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=linutronix.de
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18])
        by mx.google.com with ESMTP id li15si2817253ejb.166.2020.10.24.02.04.39;
        Sat, 24 Oct 2020 02:05:02 -0700 (PDT)
Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Authentication-Results: mx.google.com;
       dkim=pass header.i=@linutronix.de header.s=2020 header.b=FpQmBJoq;
       dkim=neutral (no key) header.i=@linutronix.de header.s=2020e;
       spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org;
       dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=linutronix.de
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S1757032AbgJWV7u (ORCPT <rfc822;crosarcplusplustest@gmail.com>
        + 99 others); Fri, 23 Oct 2020 17:59:50 -0400
Received: from lindbergh.monkeyblade.net ([23.128.96.19]:43794 "EHLO
        lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
        with ESMTP id S1757027AbgJWV7u (ORCPT
        <rfc822;linux-kernel@vger.kernel.org>);
        Fri, 23 Oct 2020 17:59:50 -0400
Received: from galois.linutronix.de (Galois.linutronix.de [IPv6:2a0a:51c0:0:12e:550::1])
        by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 591B8C0613CE;
        Fri, 23 Oct 2020 14:59:50 -0700 (PDT)
From:   Thomas Gleixner <tglx@linutronix.de>
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de;
        s=2020; t=1603490388;
        h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
         to:to:cc:cc:mime-version:mime-version:content-type:content-type:
         in-reply-to:in-reply-to:references:references;
        bh=mcqtPkA0tz7ylkWcpgHi1whok+ruukbSXl7bVbRNeHw=;
        b=FpQmBJoq1nNNC4QO/xEsdNA1Wbti7sa5bKvyG9sxwcqPPWtOcPaCfWHtjhhrHtdUsbWyXk
        WuJFdPY9XA7e+0DEWHd8Rf+IBNRbxbf0fGtk3WY35MEYWRsCO/al04Qy+n8N35/YhhZLyT
        +qyXEDBepFoJ/UzLTB1z9KkOc67HKEEspRF1UkSXJFofyra8sQxfXRyr6iIdIJ522WMsTn
        rGHA9pvAWa0xtjYG5RpmS4+VYuClBkA7FcnnuaQjQsQavxrmtjMX1yyL73Onjqp8lR1m3x
        uqEwc+8Y5+pRUNn7WDf5/n76QQ5uM03H/QHZiUgjVoT9Lqy3Ug2xR58HjkD51A==
DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de;
        s=2020e; t=1603490388;
        h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
         to:to:cc:cc:mime-version:mime-version:content-type:content-type:
         in-reply-to:in-reply-to:references:references;
        bh=mcqtPkA0tz7ylkWcpgHi1whok+ruukbSXl7bVbRNeHw=;
        b=nHmm/QYqpi4s8doFzwGapHfMVQpfgwSLj29GjpCVLTMZfVMcMdPOuaBxwzoLga1IiapECr
        VsJQfTGT65LC3sCw==
To:     Elliot Berman <eberman@codeaurora.org>,
        Peter Zijlstra <peterz@infradead.org>,
        "Paul E. McKenney" <paulmck@kernel.org>,
        Jonathan Corbet <corbet@lwn.net>
Cc:     Elliot Berman <eberman@codeaurora.org>,
        Trilok Soni <tsoni@codeaurora.org>,
        Prasad Sodagudi <psodagud@codeaurora.org>,
        linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org
Subject: Re: [PATCH] smp: Add bootcpus parameter to boot subset of CPUs
In-Reply-To: <1603404243-5536-1-git-send-email-eberman@codeaurora.org>
References: <1603404243-5536-1-git-send-email-eberman@codeaurora.org>
Date:   Fri, 23 Oct 2020 23:59:48 +0200
Message-ID: <87v9f04n8r.fsf@nanos.tec.linutronix.de>
MIME-Version: 1.0
Content-Type: text/plain
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Thu, Oct 22 2020 at 15:04, Elliot Berman wrote:
> In a heterogeneous multiprocessor system, specifying the 'maxcpus'
> parameter on kernel command line does not provide sufficient control
> over which CPUs are brought online at kernel boot time, since CPUs may
> have nonuniform performance characteristics. Thus, add bootcpus kernel
> parameter to control which CPUs should be brought online during kernel
> boot. When both maxcpus and bootcpus is set, the more restrictive of the
> two are booted.

What for? 'maxcpus' is a debug hack at best and outright dangerous on
certain architectures. Why do we need more of that? Just let the machine
boot and offline the CPUs from user space.

Thanks,

        tglx