Date: Fri, 11 Apr 2003 08:31:03 -0700 From: Terry Lambert <tlambert2@mindspring.com> To: David Xu <davidxu@freebsd.org> Cc: freebsd-threads@freebsd.org Subject: Re: patch for %gs saving Message-ID: <3E96DFB7.9E5AC29A@mindspring.com> References: <20030411053722.782152A7EA@canning.wemm.org> <012401c2ffef$e50657e0$f001a8c0@davidw2k>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3E96DFB7.9E5AC29A>