[lkml]   [2006]   [Jun]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [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.


    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2006-06-19 10:45    [W:0.022 / U:6.476 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site