public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Johannes Weiner <hannes@saeurebad.de>
To: "Peter Teoh" <htmldeveloper@gmail.com>
Cc: "Jeremy Fitzhardinge" <jeremy@goop.org>,
	LKML <linux-kernel@vger.kernel.org>,
	"Tejun Heo" <htejun@gmail.com>,
	"Dipankar Sarma" <dipankar@in.ibm.com>
Subject: Re: per cpun+ spin locks coexistence?
Date: Sun, 16 Mar 2008 21:20:29 +0100	[thread overview]
Message-ID: <87bq5e1kvm.fsf@saeurebad.de> (raw)
In-Reply-To: <804dabb00803160930t40b7c415ic38f2b9955b515ac@mail.gmail.com> (Peter Teoh's message of "Mon, 17 Mar 2008 00:30:23 +0800")

Hi Peter,

"Peter Teoh" <htmldeveloper@gmail.com> writes:

>>  > Notice above that get_cpu_var() is followed by spin_lock().   Does this
>>  > make sense?   get_cpu_var() will return a variable that is only
>>  > accessible by the current CPU - guaranteed it will not be touch (read or
>>  > write) by another CPU, right?
>>
>>  No, not true.  percpu is for stuff which is generally only touched by
>>  one CPU, but there's nothing stopping other processors from accessing it
>>  with per_cpu(var, cpu).
>
> get_cpu_var() above, will return a ptr specific for a particular CPU
> only, is correct?
>
> #define get_cpu_var(var) (*({                           \
>         extern int simple_identifier_##var(void);       \
>         preempt_disable();                              \
>         &__get_cpu_var(var); }))
>
> SMP:
>
> #define __get_cpu_var(var) \
>         (*SHIFT_PERCPU_PTR(&per_cpu_var(var), my_cpu_offset))
>
> #define SHIFT_PERCPU_PTR(__p, __offset) RELOC_HIDE((__p), (__offset))
>
> and RELOC_HIDE() i don't understand.

RELOC_HIDE is a GCC hack.  It does basically p+offset.

> So from what u said, per_cpu_var() returns uniquely for each CPU, but
> __get_cpu_var() may not be unique among the different CPU - is that
> correct?
>
> When cpuA and cpuB call get_cpu_var(), the returned ptr is specific
> only for cpuA and cpuB, right?   So yes, as u said, different cpu can
> call get_cpu_var(), but the returned ptr will be unique to each cpu,
> therefore it is guaranteed that another CPU will not get hold of the
> returned results of get_cpu_var(), right?   So why spin_lock() comes
> after get_cpu_var()?

A per-cpu variable is basically an array the size of the number of
possible CPUs in the system.  get_cpu_var() checks what current CPU we
are running on and gets the array-element corresponding to this CPU.

So, really oversimplified, get_cpu_var(foo) translates to something like
foo[smp_processor_id()].

But per_cpu(), as Jemery said, allows you to retrieve an element from
the array that is not meant for your current CPU.  So even if you run on
CPU1, you might fetch the element that is meant for use on CPU0.

But even if you don't access the cpu-local variable from other CPUs, the
element might still be a reference to a shared structure that you have
to lock properly.  Another CPU might have a reference to this same
structure as well in its per-cpu variable.

	Hannes

  reply	other threads:[~2008-03-16 20:22 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-03-12 16:17 per cpun+ spin locks coexistence? Peter Teoh
2008-03-14 17:54 ` Jeremy Fitzhardinge
2008-03-16 16:30   ` Peter Teoh
2008-03-16 20:20     ` Johannes Weiner [this message]
2008-03-17 17:06       ` Peter Teoh
2008-03-17 17:51         ` Johannes Weiner
2008-03-17 19:22         ` Eric Dumazet
2008-03-18 17:00           ` Peter Teoh
2008-03-18 17:34             ` Dipankar Sarma
2008-03-18 18:00             ` Eric Dumazet
2008-03-19 16:25               ` Peter Teoh

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=87bq5e1kvm.fsf@saeurebad.de \
    --to=hannes@saeurebad.de \
    --cc=dipankar@in.ibm.com \
    --cc=htejun@gmail.com \
    --cc=htmldeveloper@gmail.com \
    --cc=jeremy@goop.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