From: "Srivatsa S. Bhat" <srivatsa.bhat@linux.vnet.ibm.com>
To: Venki Pallipadi <venki@google.com>
Cc: Tony Luck <tony.luck@gmail.com>,
Rusty Russell <rusty@rustcorp.com.au>,
Andrew Morton <akpm@linux-foundation.org>,
KOSAKI Motohiro <kosaki.motohiro@gmail.com>,
KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>,
Mike Travis <travis@sgi.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
Subject: Re: [PATCH] Avoid mask based num_possible_cpus and num_online_cpus -v5
Date: Tue, 14 Feb 2012 02:25:33 +0530 [thread overview]
Message-ID: <4F3978C5.7080901@linux.vnet.ibm.com> (raw)
In-Reply-To: <CABeCy1YUbk35bkDLKdvf2qVVHHVJ4wEJqtMJQK3=xJO4P=KKHg@mail.gmail.com>
On 02/14/2012 02:13 AM, Venki Pallipadi wrote:
> On Mon, Feb 13, 2012 at 12:25 PM, Srivatsa S. Bhat
> <srivatsa.bhat@linux.vnet.ibm.com> wrote:
>> On 02/14/2012 01:24 AM, Tony Luck wrote:
>>
>>> On Thu, Feb 2, 2012 at 12:03 PM, Rusty Russell <rusty@rustcorp.com.au> wrote:
>>>> IIRC playing with 3 archs boot code seemed like a recipe for disaster.
>>>> Feel free to try to fix this in -next though, and see what breaks...
>>>
>>> ia64 is what breaks ... well not actually broken ... but some very
>>> weird delays that
>>> show up in different places depending on whether this patch is present.
>>>
>>> First linux-next kernel to be blessed with this patch was
>>> next-20120210. Booting it
>>> I see:
>>> [ 7.164233] Switching to clocksource itc
>>> [ 146.077315] pnp: PnP ACPI init
>>>
>>> An ugly 138.913 second delay. Digging in the code showed that the bad bits
>>> happened inside stop_machine()
>>>
>>> Reverting just this patch makes this big delay disappear:
>>>
>>> [ 32.780232] Switching to clocksource itc
>>> [ 32.832100] pnp: PnP ACPI init
>>>
>>> but notice that it takes 25 extra seconds to get to this point in the
>>> boot (and while
>>> we expect to save some time by not re-computing num_online_cpus each time we
>>> need it ... this looks to be a lot more than I'd expect!)
>>>
>>
>>
>> Oh no!! ia64 directly uses cpu_set() and cpu_clear() on cpu_online_map!!
>> Grr.. It means num_online_cpus can be different from the actual number of
>> online cpus because it doesn't go through the set_cpu_online() path.. I haven't
>> yet pin-pointed the exact problem, but this definitely doesn't look good...
>>
>
> This feels like a minefield in general. ia64, mips and um seems to
> have cpu_set and cpu_clear of cpu_online_map and/or cpu_possible_map
> in there.
>
Since I had almost never seen code using "cpu_online_map" instead of
"cpu_online_mask", I hadn't checked it while reviewing your patch... :-(
Honestly, it is only now that I realized that there is this other variant too!
Regards,
Srivatsa S. Bhat
next prev parent reply other threads:[~2012-02-13 20:55 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
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 [this message]
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=4F3978C5.7080901@linux.vnet.ibm.com \
--to=srivatsa.bhat@linux.vnet.ibm.com \
--cc=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=tony.luck@gmail.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.