linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Luck, Tony" <tony.luck@intel.com>
To: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
Cc: "Yu, Fenghua" <fenghua.yu@intel.com>,
	"linux-ia64@vger.kernel.org" <linux-ia64@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: RE: ia64: replace old cpumask functions with new one
Date: Wed, 13 Jul 2011 14:47:51 -0700	[thread overview]
Message-ID: <987664A83D2D224EAE907B061CE93D5301E9C9F80E@orsmsx505.amr.corp.intel.com> (raw)
In-Reply-To: <4E1C055C.1030103@jp.fujitsu.com>

> But ummm.. I can't understand the author expect which effect by this volatile.
> If I am correct, its volatile has no effect. we can simply remove it.

It may be a legacy from when cpumask was a simple integer type. The
boot cpu wakes up each "AP" cpu in turn - and spins looking at
cpu_callin_mask waiting to see if the cpu has really woken up,
since the AP cpu will set its own bit in this mask when it begins
execution.

Making the original integer mask a volatile was a way to make
sure that the compiler did not optimize away the re-read of
this variable in the loop.

When NR_CPUS is small enough - we still use a simple
integer for cpumask type - don't we? So if you remove
the volatile, look very carefully at this loop:

        for (timeout = 0; timeout < 100000; timeout++) {
                if (cpu_isset(cpu, cpu_callin_map))
                        break;  /* It has booted */
                udelay(100);
        }

to make sure that the cpu_isset() check really does look
at cpu_callin_map every time (and not at some cached in a
register copy of it). Booting would become painfully slow
if we get stuck for 10 seconds per cpu just here.

-Tony



      reply	other threads:[~2011-07-13 21:47 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-06-23 10:55 ia64: replace old cpumask functions with new one KOSAKI Motohiro
2011-07-06 21:14 ` Tony Luck
2011-07-12  8:27   ` KOSAKI Motohiro
2011-07-13 21:47     ` Luck, Tony [this message]

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=987664A83D2D224EAE907B061CE93D5301E9C9F80E@orsmsx505.amr.corp.intel.com \
    --to=tony.luck@intel.com \
    --cc=fenghua.yu@intel.com \
    --cc=kosaki.motohiro@jp.fujitsu.com \
    --cc=linux-ia64@vger.kernel.org \
    --cc=linux-kernel@vger.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).