Date: Fri, 11 Apr 2003 09:01:01 -0400 (EDT) From: Daniel Eischen <eischen@pcnet1.pcnet.com> To: Julian Elischer <julian@elischer.org> Cc: freebsd-threads@freebsd.org Subject: Re: patch for %gs saving Message-ID: <Pine.GSO.4.10.10304110855140.12636-100000@pcnet1.pcnet.com> In-Reply-To: <Pine.GSO.4.10.10304110832200.12636-100000@pcnet1.pcnet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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). We'd have to hack __sys_[sg]etcontext() to avoid restoring %gs for a KSE enabled application. This muddies up [gs]et_mcontext() because I think you do want %gs in some instances. Either that, or the UTS will be required to have userland versions of [gs]etcontext() so that %gs (or whatever) is ignored. -- Dan Eischen
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.GSO.4.10.10304110855140.12636-100000>