Messages in this thread | | | Date | Tue, 18 Mar 2008 01:06:33 +0800 | From | "Peter Teoh" <> | Subject | Re: 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 <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?
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).
-- Regards, Peter Teoh
| |