All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dou Liyang <douly.fnst@cn.fujitsu.com>
To: Peter Zijlstra <peterz@infradead.org>
Cc: linux-kernel@vger.kernel.org, x86@kernel.org,
	linux-acpi@vger.kernel.org, linux-doc@vger.kernel.org,
	tglx@linutronix.de, mingo@redhat.com, corbet@lwn.net,
	rjw@rjwysocki.net, lenb@kernel.org, hpa@zytor.com
Subject: Re: [PATCH 1/5] x86/smpboot: Add the missing description of possible_cpus
Date: Wed, 21 Mar 2018 17:41:45 +0800	[thread overview]
Message-ID: <1dfcdb3d-6a92-8654-7cc4-ef262ddb0915@cn.fujitsu.com> (raw)
In-Reply-To: <076196e1-c181-ba44-f912-61bd279b345b@cn.fujitsu.com>



At 03/21/2018 05:34 PM, Dou Liyang wrote:
> Hi Peter,
> 
> At 03/21/2018 05:08 PM, Peter Zijlstra wrote:
>> On Wed, Mar 21, 2018 at 01:33:24PM +0800, Dou Liyang wrote:
>>> How about:
>>>
>>> possible_cpus=    [s390,x86_64] Set the number of possible CPUs which
>>>         are determined by the ACPI tables MADT or mptables by
>>>         default. possible_cpus=n : n >= 1 enforces the possible
>>>         number to be 'n'.
>>>         While nr_cpus is also be set: nr_cpus=m, choice the
>>>         minimum one for the number of possible CPUs.
>>
>> So what is the exact difference between possible_cpus and nr_cpus ? I
> 
> the possible_cpus= can reset the number of possible CPUs, even bigger
> than 'num_processors + disabled_cpus', But nr_cpus= can't.
        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
       the maximum number kernel gets from ACPI/mptables, no matter what
number nr_cpus= is, the number of possible CPUs will not bigger than it.

>
>> konw maxcpus= limits the number of CPUs we bring up, and possible_cpus
>> limits the possible_map, but I'm not entirely sure what nr_cpus does
>> here.
>>
> 
> nr_cpus can limited the maximum CPUs that the kernel could support.
> 
> Here is a double check in case of using them at the same time, even if I
> think just using possible_cpus= is enough. :-)
> 
> Thanks,
>      dou.
>>
>>

WARNING: multiple messages have this Message-ID (diff)
From: Dou Liyang <douly.fnst@cn.fujitsu.com>
To: Peter Zijlstra <peterz@infradead.org>
Cc: <linux-kernel@vger.kernel.org>, <x86@kernel.org>,
	<linux-acpi@vger.kernel.org>, <linux-doc@vger.kernel.org>,
	<tglx@linutronix.de>, <mingo@redhat.com>, <corbet@lwn.net>,
	<rjw@rjwysocki.net>, <lenb@kernel.org>, <hpa@zytor.com>
Subject: Re: [PATCH 1/5] x86/smpboot: Add the missing description of possible_cpus
Date: Wed, 21 Mar 2018 17:41:45 +0800	[thread overview]
Message-ID: <1dfcdb3d-6a92-8654-7cc4-ef262ddb0915@cn.fujitsu.com> (raw)
In-Reply-To: <076196e1-c181-ba44-f912-61bd279b345b@cn.fujitsu.com>



At 03/21/2018 05:34 PM, Dou Liyang wrote:
> Hi Peter,
> 
> At 03/21/2018 05:08 PM, Peter Zijlstra wrote:
>> On Wed, Mar 21, 2018 at 01:33:24PM +0800, Dou Liyang wrote:
>>> How about:
>>>
>>> possible_cpus=    [s390,x86_64] Set the number of possible CPUs which
>>>         are determined by the ACPI tables MADT or mptables by
>>>         default. possible_cpus=n : n >= 1 enforces the possible
>>>         number to be 'n'.
>>>         While nr_cpus is also be set: nr_cpus=m, choice the
>>>         minimum one for the number of possible CPUs.
>>
>> So what is the exact difference between possible_cpus and nr_cpus ? I
> 
> the possible_cpus= can reset the number of possible CPUs, even bigger
> than 'num_processors + disabled_cpus', But nr_cpus= can't.
        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
       the maximum number kernel gets from ACPI/mptables, no matter what
number nr_cpus= is, the number of possible CPUs will not bigger than it.

>
>> konw maxcpus= limits the number of CPUs we bring up, and possible_cpus
>> limits the possible_map, but I'm not entirely sure what nr_cpus does
>> here.
>>
> 
> nr_cpus can limited the maximum CPUs that the kernel could support.
> 
> Here is a double check in case of using them at the same time, even if I
> think just using possible_cpus= is enough. :-)
> 
> Thanks,
>      dou.
>>
>>

WARNING: multiple messages have this Message-ID (diff)
From: Dou Liyang <douly.fnst@cn.fujitsu.com>
To: Peter Zijlstra <peterz@infradead.org>
Cc: <linux-kernel@vger.kernel.org>, <x86@kernel.org>,
	<linux-acpi@vger.kernel.org>, <linux-doc@vger.kernel.org>,
	<tglx@linutronix.de>, <mingo@redhat.com>, <corbet@lwn.net>,
	<rjw@rjwysocki.net>, <lenb@kernel.org>, <hpa@zytor.com>
Subject: Re: [PATCH 1/5] x86/smpboot: Add the missing description of possible_cpus
Date: Wed, 21 Mar 2018 17:41:45 +0800	[thread overview]
Message-ID: <1dfcdb3d-6a92-8654-7cc4-ef262ddb0915@cn.fujitsu.com> (raw)
In-Reply-To: <076196e1-c181-ba44-f912-61bd279b345b@cn.fujitsu.com>



At 03/21/2018 05:34 PM, Dou Liyang wrote:
> Hi Peter,
> 
> At 03/21/2018 05:08 PM, Peter Zijlstra wrote:
>> On Wed, Mar 21, 2018 at 01:33:24PM +0800, Dou Liyang wrote:
>>> How about:
>>>
>>> possible_cpus=    [s390,x86_64] Set the number of possible CPUs which
>>>         are determined by the ACPI tables MADT or mptables by
>>>         default. possible_cpus=n : n >= 1 enforces the possible
>>>         number to be 'n'.
>>>         While nr_cpus is also be set: nr_cpus=m, choice the
>>>         minimum one for the number of possible CPUs.
>>
>> So what is the exact difference between possible_cpus and nr_cpus ? I
> 
> the possible_cpus= can reset the number of possible CPUs, even bigger
> than 'num_processors + disabled_cpus', But nr_cpus= can't.
        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
       the maximum number kernel gets from ACPI/mptables, no matter what
number nr_cpus= is, the number of possible CPUs will not bigger than it.

>
>> konw maxcpus= limits the number of CPUs we bring up, and possible_cpus
>> limits the possible_map, but I'm not entirely sure what nr_cpus does
>> here.
>>
> 
> nr_cpus can limited the maximum CPUs that the kernel could support.
> 
> Here is a double check in case of using them at the same time, even if I
> think just using possible_cpus= is enough. :-)
> 
> Thanks,
>      dou.
>>
>>


--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

  reply	other threads:[~2018-03-21  9:41 UTC|newest]

Thread overview: 48+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-03-20 11:04 [PATCH 0/5] x86/cpu_hotplug: one bug fix and four cleanup Dou Liyang
2018-03-20 11:04 ` Dou Liyang
2018-03-20 11:04 ` Dou Liyang
2018-03-20 11:04 ` [PATCH 1/5] x86/smpboot: Add the missing description of possible_cpus Dou Liyang
2018-03-20 11:04   ` Dou Liyang
2018-03-20 11:04   ` Dou Liyang
2018-03-20 12:37   ` Peter Zijlstra
2018-03-20 12:37     ` Peter Zijlstra
2018-03-21  5:33     ` Dou Liyang
2018-03-21  5:33       ` Dou Liyang
2018-03-21  5:33       ` Dou Liyang
2018-03-21  9:08       ` Peter Zijlstra
2018-03-21  9:08         ` Peter Zijlstra
2018-03-21  9:34         ` Dou Liyang
2018-03-21  9:34           ` Dou Liyang
2018-03-21  9:34           ` Dou Liyang
2018-03-21  9:41           ` Dou Liyang [this message]
2018-03-21  9:41             ` Dou Liyang
2018-03-21  9:41             ` Dou Liyang
2018-03-21  9:41         ` Thomas Gleixner
2018-03-21  9:41           ` Thomas Gleixner
2018-03-20 11:04 ` [PATCH 2/5] x86/cpu_hotplug: Update the link of cpu_hotplug.rst Dou Liyang
2018-03-20 11:04   ` Dou Liyang
2018-03-20 11:04   ` Dou Liyang
2018-03-20 11:04 ` [PATCH 3/5] x86/smpboot: Make the check code more clear in prefill_possible_map() Dou Liyang
2018-03-20 11:04   ` Dou Liyang
2018-03-20 11:04   ` Dou Liyang
2018-03-20 12:39   ` Peter Zijlstra
2018-03-20 12:39     ` Peter Zijlstra
2018-03-21  5:38     ` Dou Liyang
2018-03-21  5:38       ` Dou Liyang
2018-03-21  5:38       ` Dou Liyang
2018-03-20 11:04 ` [PATCH 4/5] acpi/processor: Fix the return value of acpi_processor_ids_walk() Dou Liyang
2018-03-20 11:04   ` Dou Liyang
2018-03-20 11:04   ` Dou Liyang
2018-05-19 15:06   ` Thomas Gleixner
2018-05-19 15:06     ` Thomas Gleixner
2018-05-22  1:47     ` Dou Liyang
2018-05-22  1:47       ` Dou Liyang
2018-05-22  1:47       ` Dou Liyang
2018-05-23  1:34       ` Dou Liyang
2018-05-23  1:34         ` Dou Liyang
2018-05-23  1:34         ` Dou Liyang
2018-05-23  8:08         ` Rafael J. Wysocki
2018-05-23  8:08           ` Rafael J. Wysocki
2018-03-20 11:04 ` [PATCH 5/5] acpi/processor: Make the acpi_duplicate_processor_id() static Dou Liyang
2018-03-20 11:04   ` Dou Liyang
2018-03-20 11:04   ` Dou Liyang

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1dfcdb3d-6a92-8654-7cc4-ef262ddb0915@cn.fujitsu.com \
    --to=douly.fnst@cn.fujitsu.com \
    --cc=corbet@lwn.net \
    --cc=hpa@zytor.com \
    --cc=lenb@kernel.org \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=peterz@infradead.org \
    --cc=rjw@rjwysocki.net \
    --cc=tglx@linutronix.de \
    --cc=x86@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.