Messages in this thread | | | Date | Mon, 19 Jun 2006 10:42:43 +0200 | From | Zoltan Menyhart <> | Subject | Re: [discuss] Re: FOR REVIEW: New x86-64 vsyscall vgetcpu() |
| |
Brent Casavant wrote:
> 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.
Quite O.K. for me.
Andi Kleen wrote:
>>Well, if every process had a page of its own, what would the context >>switch overhead be?
> For process zero, for thread quite high on x86 because you > would need per CPU page tables. Doing that would be extremly > nasty because you would potentially need to allocate a new > set of page tables every time the process is scheduled to a new > CPU it hasn't run on before.
Probably I have not explained it correctly: - The "information page" (that includes the current CPU no.) is not a per CPU page - This page is just another page that is mapped at a "well known" user virtual address (for those who are interested in) - As you do not do any special action for each user page on context switch, there is nothing to to this page either - The scheduler sometimes migrates a task, then it updates the the current CPU number on the "information page"
> My reference was more to high suggestion of keeping a second version > of task_struct for export. That would require changing everything > in task struct that is changed on switch_to and should be exported > in the other function too.
It depends on what else can be in this "information page". As for the current CPU no., you need a single store on each task migration.
Thanks,
Zoltan - 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/
| |