[lkml]   [2008]   [Mar]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: per cpun+ spin locks coexistence?
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 <> 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?

But supposed u really want to put a spin_lock(), just to be sure
nobody is even reading it, or modifying it, so then what is the
original purpose of get_cpu_var() - is it not to implement something
that can be parallelized among different CPU, without affecting each
other, and using no locks?

The dual use of spin_lock+get_cpu_var() confuses me here :-). (not
the per_cpu(), which I agree is supposed to be callabe from all the
different CPU, for purpose of enumeration or data collection).

Peter Teoh

 \ /
  Last update: 2008-03-17 18:09    [W:0.086 / U:7.076 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site