mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Bharata B Rao <bharata@in.ibm.com>
To: Zwane Mwaikambo <zwane@arm.linux.org.uk>
Cc: Andrew Morton <akpm@osdl.org>,
	Linux Kernel <linux-kernel@vger.kernel.org>,
	Andi Kleen <ak@suse.de>
Subject: Re: [PATCH] i386 boottime for_each_cpu broken
Date: Thu, 11 Aug 2005 12:11:05 +0530	[thread overview]
Message-ID: <20050811064105.GC3937@in.ibm.com> (raw)
In-Reply-To: <Pine.LNX.4.61.0508102220070.16483@montezuma.fsmlabs.com>

On Thu, Aug 11, 2005 at 04:54:44AM +0000, Zwane Mwaikambo wrote:
> for_each_cpu walks through all processors in cpu_possible_map, which is 
> defined as cpu_callout_map on i386 and isn't initialised until all 
> processors have been booted. This breaks things which do for_each_cpu 
> iterations early during boot. So, define cpu_possible_map as a bitmap with 
> NR_CPUS bits populated. This was triggered by a patch i'm working on which 
> does alloc_percpu before bringing up secondary processors.
> 

Zwane,

I don't know the context of your work here, but a couple of 
observations.

Since you populate cpu_possible_map with NR_CPUS, alloc_percpu()
would end up allocating for all NR_CPUS.  Wouldn't you have achieved
the same thing by compile time allocation ? Wouldn't this change
lead to NR_CPUS allocations from alloc_percpu() for all users ?

Now since you have separated cpu_possible_map from cpu_callout_map,
do we need to reflect cpu_possible_map with the value from
cpu_callout_map after the cpu_callout_map is initialized fully from
smp_prepare_cpus().

BTW, I am working on Kiran's dynamic percpu allocator patch and making
it cpu hotplug aware. With that, alloc_percpu would initially allocate
only for the possible cpus and would allocate for other cpus as and when
they come up.

Regards,
Bharata.

  reply	other threads:[~2005-08-11  6:41 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-08-11  4:59 Zwane Mwaikambo
2005-08-11  6:41 ` Bharata B Rao [this message]
2005-08-11 21:33   ` Zwane Mwaikambo
2005-08-11 10:54 ` Andi Kleen
2005-08-11 17:44   ` Zwane Mwaikambo
     [not found] <200509050815.j858FLxR027791@hera.kernel.org>
2005-09-09  7:26 ` Andrew Morton
2005-09-09  7:43   ` Zwane Mwaikambo

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=20050811064105.GC3937@in.ibm.com \
    --to=bharata@in.ibm.com \
    --cc=ak@suse.de \
    --cc=akpm@osdl.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=zwane@arm.linux.org.uk \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®