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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
