From: Andrew Morton <akpm@linux-foundation.org>
To: Venkatesh Pallipadi <venki@google.com>
Cc: KOSAKI Motohiro <kosaki.motohiro@gmail.com>,
KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>,
Mike Travis <travis@sgi.com>,
"Srivatsa S. Bhat" <srivatsa.bhat@linux.vnet.ibm.com>,
"Paul E. McKenney" <paul.mckenney@linaro.org>,
"Rafael J. Wysocki" <rjw@sisk.pl>,
Paul Gortmaker <paul.gortmaker@windriver.com>,
linux-kernel@vger.kernel.org,
Rusty Russell <rusty@rustcorp.com.au>
Subject: Re: [PATCH] Avoid mask based num_possible_cpus and num_online_cpus -v5
Date: Wed, 1 Feb 2012 14:01:25 -0800 [thread overview]
Message-ID: <20120201140125.c656df41.akpm@linux-foundation.org> (raw)
In-Reply-To: <1328055439-9441-1-git-send-email-venki@google.com>
On Tue, 31 Jan 2012 16:17:19 -0800
Venkatesh Pallipadi <venki@google.com> wrote:
> Kernel's notion of possible cpus (from include/linux/cpumask.h)
> * cpu_possible_mask- has bit 'cpu' set iff cpu is populatable
>
> * The cpu_possible_mask is fixed at boot time, as the set of CPU id's
> * that it is possible might ever be plugged in at anytime during the
> * life of that system boot.
>
> #define num_possible_cpus() cpumask_weight(cpu_possible_mask)
>
> and on x86 cpumask_weight() calls hweight64 and hweight64 (on older kernels
> and systems with !X86_FEATURE_POPCNT) or a popcnt based alternative.
>
> i.e, We needlessly go through this mask based calculation everytime
> num_possible_cpus() is called.
>
> The problem is there with cpu_online_mask() as well, which is fixed value at
> boot time in !CONFIG_HOTPLUG_CPU case and should not change that often even
> in HOTPLUG case.
>
> Though most of the callers of these two routines are init time (with few
> exceptions of runtime calls), it is cleaner to use variables
> and not go through this repeated mask based calculation.
Looks good to me.
> --- a/kernel/cpu.c
> +++ b/kernel/cpu.c
> @@ -604,9 +604,13 @@ EXPORT_SYMBOL(cpu_all_bits);
> #ifdef CONFIG_INIT_ALL_POSSIBLE
> static DECLARE_BITMAP(cpu_possible_bits, CONFIG_NR_CPUS) __read_mostly
> = CPU_BITS_ALL;
> +unsigned int nr_possible_cpus __read_mostly = CONFIG_NR_CPUS;
> #else
> static DECLARE_BITMAP(cpu_possible_bits, CONFIG_NR_CPUS) __read_mostly;
> +unsigned int nr_possible_cpus __read_mostly;
> #endif
> +EXPORT_SYMBOL(nr_possible_cpus);
What the heck is CONFIG_INIT_ALL_POSSIBLE?
<blames Rusty>
: 1) Some archs (m32, parisc, s390) set possible_map to all 1, so we add a
: CONFIG_INIT_ALL_POSSIBLE for this rather than break them.
Seems strange. Do these architectures really need to initialise
cpu_possible_map at compile-time, when all the other architectures
manage to do it at runtime?
next prev parent reply other threads:[~2012-02-01 22:01 UTC|newest]
Thread overview: 50+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-01-18 2:07 [PATCH] Avoid mask based num_possible_cpus and num_online_cpus Venkatesh Pallipadi
2012-01-18 5:55 ` KOSAKI Motohiro
2012-01-18 18:52 ` Venki Pallipadi
2012-01-18 19:20 ` KOSAKI Motohiro
2012-01-19 20:01 ` Venkatesh Pallipadi
2012-01-19 20:40 ` KOSAKI Motohiro
2012-01-21 1:01 ` Venki Pallipadi
2012-01-19 20:43 ` Srivatsa S. Bhat
2012-01-20 23:09 ` Venki Pallipadi
2012-01-20 23:45 ` KOSAKI Motohiro
2012-01-20 23:55 ` Venki Pallipadi
2012-01-23 5:22 ` Srivatsa S. Bhat
2012-01-23 19:28 ` Venki Pallipadi
2012-01-24 2:34 ` [PATCH] Avoid mask based num_possible_cpus and num_online_cpus -v3 Venkatesh Pallipadi
2012-01-24 19:22 ` Srivatsa S. Bhat
2012-01-24 19:30 ` KOSAKI Motohiro
2012-01-24 21:01 ` Venki Pallipadi
2012-01-24 23:25 ` [PATCH] Avoid mask based num_possible_cpus and num_online_cpus -v4 Venkatesh Pallipadi
2012-01-26 17:22 ` Srivatsa S. Bhat
2012-01-26 17:27 ` Srivatsa S. Bhat
2012-01-26 21:25 ` KOSAKI Motohiro
2012-01-26 23:22 ` Andrew Morton
2012-01-27 23:58 ` Venki Pallipadi
2012-02-01 0:17 ` [PATCH] Avoid mask based num_possible_cpus and num_online_cpus -v5 Venkatesh Pallipadi
2012-02-01 22:01 ` Andrew Morton [this message]
2012-02-02 20:03 ` Rusty Russell
2012-02-02 20:19 ` Andrew Morton
2012-02-02 21:00 ` Venki Pallipadi
2012-02-13 19:54 ` Tony Luck
2012-02-13 20:04 ` Venki Pallipadi
2012-02-13 20:25 ` Srivatsa S. Bhat
2012-02-13 20:43 ` Venki Pallipadi
2012-02-13 20:55 ` Srivatsa S. Bhat
2012-02-13 20:44 ` Srivatsa S. Bhat
2012-02-13 21:57 ` Tony Luck
2012-02-14 9:25 ` Rusty Russell
2012-02-14 21:35 ` Srivatsa S. Bhat
2012-02-14 21:47 ` Srivatsa S. Bhat
2012-02-14 23:00 ` Tony Luck
2012-02-14 23:00 ` Tony Luck
2012-02-14 22:49 ` [PATCH 0/3] Cleanup raw handling of online/possible map Venkatesh Pallipadi
2012-02-14 22:49 ` [PATCH 1/3] hexagon: Avoid raw handling of cpu_possible_map Venkatesh Pallipadi
2012-02-14 22:49 ` [PATCH 2/3] mips: Avoid raw handling of cpu_possible_map/cpu_online_map Venkatesh Pallipadi
2012-02-27 22:19 ` David Daney
2012-02-14 22:49 ` [PATCH 3/3] um: Avoid raw handling of cpu_online_map Venkatesh Pallipadi
2012-02-27 21:55 ` [PATCH] Avoid mask based num_possible_cpus and num_online_cpus -v5 David Daney
2012-02-27 22:07 ` Andrew Morton
2012-02-27 22:16 ` David Daney
2012-03-01 18:32 ` Venki Pallipadi
2012-02-28 5:01 ` Stephen Rothwell
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=20120201140125.c656df41.akpm@linux-foundation.org \
--to=akpm@linux-foundation.org \
--cc=kosaki.motohiro@gmail.com \
--cc=kosaki.motohiro@jp.fujitsu.com \
--cc=linux-kernel@vger.kernel.org \
--cc=paul.gortmaker@windriver.com \
--cc=paul.mckenney@linaro.org \
--cc=rjw@sisk.pl \
--cc=rusty@rustcorp.com.au \
--cc=srivatsa.bhat@linux.vnet.ibm.com \
--cc=travis@sgi.com \
--cc=venki@google.com \
/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.