Re: [PATCH] percpu data: only iterate over possible CPUs

On Thu, Feb 09, 2006 at 12:37:29PM -0800, Andrew Morton wrote:
> 
> There is no proposal to change cpu_present_map.
> 
> The problem is cpu_possible_map.  That is presently being initialised to
> CPU_MASK_ALL, which adversely affects perfoermance.  An NR_CPUS=16 kernel
> on a 2-way presently has cpu_possible_map=0xffff, which will hurt.

Think i miss typed earlier. What you proposed is the correct solution.

I will followup with similar change on ia64 as well, (currently we do this
in smp_build_cpu_map()). And add something similar to what we did for 
x86_64.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

---

• References:
  • Re: [PATCH] percpu data: only iterate over possible CPUs
    • From: Nathan Lynch <[email protected]>
  • Re: [PATCH] percpu data: only iterate over possible CPUs
    • From: Ashok Raj <[email protected]>
  • Re: [PATCH] percpu data: only iterate over possible CPUs
    • From: Andrew Morton <[email protected]>
  • Re: [PATCH] percpu data: only iterate over possible CPUs
    • From: Ashok Raj <[email protected]>
  • Re: [PATCH] percpu data: only iterate over possible CPUs
    • From: Andrew Morton <[email protected]>

• Prev by Date: Re: [PATCH] Megaraid cleanup
• Next by Date: Re: [PATCH v2 02/07] cpuset use combined atomic_inc_return calls
• Previous by thread: Re: [PATCH] percpu data: only iterate over possible CPUs
• Next by thread: Re: [PATCH] percpu data: only iterate over possible CPUs
• Index(es):
  • Date
  • Thread

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]