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: Mon, 17 Mar 2008 18:51:34 +0100	[thread overview]
Message-ID: <87tzj5xmqh.fsf@saeurebad.de> (raw)
In-Reply-To: <804dabb00803171006i4423c5b6w58bd95116510d3f5@mail.gmail.com> (Peter Teoh's message of "Tue, 18 Mar 2008 01:06:33 +0800")

Hi,

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

> Thanks for the explanation, much apologies for this newbie discussion.
>   But I still find it inexplicable:
>
> On Mon, Mar 17, 2008 at 4:20 AM, Johannes Weiner <hannes@saeurebad.de> wrote:
>>
>>  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()].
>>
>
> Ok, so calling get_cpu_var() always return the array-element for the
> current CPU, and since by design, only the current CPU can
> modify/write to this array element (this is my assumption - correct?),
> and the other CPU will just read it (using the per_cpu construct).
> So far correct?   So why do u still need to spin_lock() to lock other
> CPU from accessing - the other CPU will always just READ it, so just
> go ahead and let them read it.   Seemed like it defeats the purpose of
> get_cpu_var()'s design?

You ignore the fact that there are structures and pointers in C :) One
and the same object may be referenced from different structure objects.

For example you have an object foo saved in a cpu-local variable and
this object references another object bar (foo.bar), you might do
whatever you want to do with foo.  But if bar is a structure you might
still have to lock when you want to change the fields of it to prevent
races if this bar object can be referenced from another point like an
instance of some_struct:

PER-CPU [foo|foo|foo]
          |   |   |
          |   |   \
          |   \    +---> [bar]
          \    +---> [bar]
           +---> [bar] <--+
                           \
                       [some_struct]

A foo _might_ be protected by cpu-locality but as you can see, bar can
only be changed under lock if it is modified through foo _and_
some_struct.

I hope this clears it.  Please correct me if I am wrong or supply a
better scenario than this ;)

	Hannes

  reply	other threads:[~2008-03-17 17:53 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
2008-03-17 17:06       ` Peter Teoh
2008-03-17 17:51         ` Johannes Weiner [this message]
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=87tzj5xmqh.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