patch for %gs saving

[Julian Elischer]

On Fri, 11 Apr 2003, Daniel Eischen wrote:

> On Thu, 10 Apr 2003, Julian Elischer wrote:
> > 
> > On Fri, 11 Apr 2003, Daniel Eischen wrote:
> > 
> > > On Thu, 10 Apr 2003, Peter Wemm wrote:
> > > 
> > > > "David Xu" wrote:
> > > > > Here is the patch for kernel to save %gs,
> > > > > it works well on my machine.
> > > > > http://people.freebsd.org/~davidxu/i386_gs.diff
> > > > > Daniel, is this the reason in your libpthread
> > > > > patch that doesn't use getcontext syscall ?
> > > > 
> > > > To put some background on the issue, there is a reason why we did not
> > > > do this.  %gs is not used by the kernel, so it does not normally need to
> > > > be saved and restored on every trap into the kernel.  Setting a segment
> > > > register is Really Slow - measured in hundreds of clock cycles.
> > > > 
> > > > So, we normally only touch %gs when we context switch to a different process
> > > > that may have a different %gs.  Or when one of the context syscalls wants
> > > > it changed.  We cannot avoid touching %fs because we use it for kernel
> > > > private data.  But if it wasn't for that, we wouldn't be touching
> > > > %fs for regular traps/syscalls/etc either.
> > > > 
> > > > Bruce Evans understands this better than I do, I would suggest not making
> > > > this change without talking about it with him first.
> > > 
> > > BTW, it's not really a big deal for the UTS to restore %gs
> > > (or probably whatever it ends up being on other archs) before
> > > continuing a thread.
> > 
> > I put it to you that %gs should be a way of finding the current KSE
> > mailbox
> 
> It is already.
> 
> > (upcall mailbox) which will NOT CHANGE when a thread is changed in
> > userland. one simply changes the curthread pointer in the KSE (upcall)
> > mailbox, leaving %gs the same.
> > 
> > %gs should never change for a single KSE as it goes in and out of the
> > kernel, it must always have the same mailbox.
> 
> The problem is switching a thread _between_ KSEs.  If there are
> multiple KSEs in a KSEG, then threads can be migrated between
> those KSEs by the UTS.  When a thread blocks in the kernel and
> then completes, there is no guarantee that the completion upcall
> will occur on the same KSE in which the thread was running when
> it blocked.  Right now, there is one scheduling queue for each
> KSEG (in the UTS), so there is currently no notion of binding
> threads to specific KSEs within a KSEG.  If we want to bind
> threads to specific KSEs, then we need some sort of load
> balancing in the UTS and then still need the ability to
> migrate threads.
> 
> If you continue a thread on another KSE, then you have to adjust
> it's %gs.  And this gets a bit more complicated when you think
> about signal handlers and the fact that %gs is in the interrupted
> context that gets passed to the signal handler (which the application
> can use to setcontext() to).

no, you shouldn't touch %gs
the KSE you are shifting to already has the right value in %gs
don't overwrite it..
(don't save %gs, don't reload it)

> 
> -- 
> Dan Eischen
> 
>