Messages in this thread | | | Date | Fri, 16 Jun 2006 14:36:52 +0200 | From | Zoltan Menyhart <> | Subject | Re: FOR REVIEW: New x86-64 vsyscall vgetcpu() |
| |
Just to make sure I understand it correctly... Assuming I have allocated per CPU data (numa control, etc.) pointed at by:
void *per_cpu[MAXCPUS];
Assuming a per CPU variable has got an "offset" in each per CPU data area. Accessing this variable can be done as follows:
err = vgetcpu(&my_cpu, ...); if (err) goto .... pointer = (typeof pointer) (per_cpu[my_cpu] + offset); // use "pointer"...
It is hundred times more long than "__get_per_cpu(var)++".
As we do not know when we can be moved to another CPU, "vgetcpu()" has to be called again after a "reasonable short" time.
My idea is to map the current task structure at an arch. dependent virtual address into the user space (obviously in RO).
#define current ((struct task_struct *) 0x...)
No more need to for "vgetcpu()" at all. The example above becomes:
pointer = (typeof pointer) (per_cpu[current->thread_info.cpu] + offset); // use "pointer"...
As obtaining "pointer" does not cost much, it can be re-calculated at each usage => no problem to know when to recheck it, there is less chance for using the data of a neighbor.
Regards,
Zoltan Menyhart - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |