Messages in this thread | | | Date | Fri, 16 Jun 2006 10:36:32 -0500 (CDT) | From | Brent Casavant <> | Subject | Re: FOR REVIEW: New x86-64 vsyscall vgetcpu() |
| |
On Fri, 16 Jun 2006, Andi Kleen wrote:
> On Friday 16 June 2006 14:36, Zoltan Menyhart wrote:
> > 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...) > > This means it cannot be cache colored (because you would need a static > offset) and you couldn't share task_structs on a page. > > Also you would make task_struct part of the userland ABI which > seems like a very very bad idea to me. It means we couldn't change > it anymore.
To this last point, it might be more reasonable to map in a page that contained a new structure with a stable ABI, which mirrored some of the task_struct information, and likely other useful information as needs are identified in the future. In any case, it would be hard to beat a single memory read for performance.
Cache-coloring and kernel bookkeeping effects could be minimized if this was provided as an mmaped page from a device driver, used only by applications which care. This does work somewhat contrary to the idea of getting support into glibc, unless glibc only used this capability when asked to through some sort of environment variable or other run-time configuration.
Brent
-- Brent Casavant All music is folk music. I ain't bcasavan@sgi.com never heard a horse sing a song. Silicon Graphics, Inc. -- Louis Armstrong - 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/
| |