patch for %gs saving

[Terry Lambert]

David Xu wrote:
> Yes, I know loading a descriptor is slow, but in real world, such optimization
> will be lost in real work noise. And setcontext syscall is broken by this
> optimization, userland will fail to set his context in atomic operation,
> set pcb->gs = userland_gs does not work, so the cost is obviously, I can optimize
> my patch to only save and restore %gs at trap and interrupt time,  when entering
> kernel, I can always zero %gs because kernel does not use it, I think this can
> reduce clock cycles at context switch, this might be better than current code
> which loading %gs at every context switch.

If it's a threaded program, you are probably going to have to
reload the %gs on a contex switch.  If it's not, you can lazy
bind it, meaning that you only reload it when you go from one
threaded process to a different threaded process, and leave it
alone otherwise (check its value where you would reload it for
a threaded process, in case some other unthreaded process has
decided to use it; boils down to a compare-if-different-reload,
in both cases).

In the UTS, you can also lazy bind the reload, since if you go
to sleep and end up rescheduling the thread, it will have the
same value as previously.  With the kernel support, you will be
safe to do this.

The one thing that this could result in is, if the process is in
the UTS, and another process has changed %gs, such that when you
get the quantum from the kernel, it would reload %gs, and then
return to user space, and the UTS would again reload %gs to then
schedule another user space thread.  The only way I can see to
avoid this latency would be for the kernel to know the process
is in the UTS, before the place where the UTS would reload %gs.
If you could know this, then you could avoid the dual reload,
by having the kernel *not* reload %gs, even if it's changed, in
that case.  Thus the UTS becomes compare-if-different-reload as
well.  You could probably do this with a flag in a mailbox that
is associated with the UTS.

The "extra" cost is a compare in both places, which (probably)
avoids a statistically significant number of %gs reloads.

-- Terry