I haven't thought too much about it, but doing it in a vdso seems reasonable. It would mean that the scheduler hot path would need to know about its address though. > > You appear to summarize the two things that are added to the kernel with > > this RFC patch: > > - faster getcpu(): 12.7 ns -> 0.3 ns > > Yeah, I figured that out the second time I read your email and re-read > the original message, but I apparently forgot to fix up the email I > was typing. The high speed users seem to have all switched to using LSL directly, which is even faster. Since there are already users it cannot be changed anymore. Should probably just document this as an official ABI, and provide some standard include file with inline code. > IIRC some other OS's use gs as a userspace per-cpu pointer instead of > a per-thread pointer. Would we want to consider enabling that? > This may interact oddly with the WIP wrgsbase stuff. (Grr, Intel, why > couldn't you have made wrgsbase reset the gs selector to zero? That > would have been so much nicer.) Applications really want the extra address registers. For example OpenJDK could free a GPR. And it's needed for the TLS of user space threads, which are becoming more and more popular. So there are already more important users queued. -Andi -- ak@xxxxxxxxxxxxxxx -- Speaking for myself only. -- To unsubscribe from this list: send the line "unsubscribe linux-api" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
