Messages in this thread | ![/](/images/icornerl.gif) | | Subject | RE: [PATCH 0/5] Generic smp_call_function(), improvements, and smp_call_function_single() | Date | Mon, 24 Mar 2008 09:45:06 -0700 | From | "Luck, Tony" <> |
| |
> Funky, how does accessing other CPU's per-cpu variables work on ia64 > then? Perhaps I made some false assumptions.
The per-cpu memory is mapped at two different spots in the kernel virtual memory. When cpuA wants to access per-cpu memory that belongs to cpuB it can use the mappings that allow access to every percpu area (which may just be indexing by cpu number into a big block of memory that has all the per-cpu spaces ... or some more complex arithmetic and pointers for NUMA systems where the per-cpu memory ought to be allocated out of memory on the right node for the cpu that it refers to).
When any cpu wants to access its own per-cpu data, it can do so via the per-cpu mapping (which is much more efficient from a code generation perspective at the per-cpu virtual area is the top 64K of virtual address space, so can be accessed with a small negative offset from register r0).
This is why lists can be a problem ... since the same memory can be accessed via two different virtual addresses, things can get badly knotted when the two different addresses get used in different parts of the code. Then operations like "list_empty()" may give the wrong answer because the virtual address used for head->next isn't the same as that used for head ... but they both refer to the same underlying object.
> Unfortunately I have no access to any IA64 machines, so I either > have to yank the ia64 bits (which is unfortunate, since Alan tests > on those :-) or rely on a bit of help from you and/or others in > getting that bit right.
I'll see if I can figure out what is going wrong.
-Tony
| ![\](/images/icornerr.gif) |