From owner-freebsd-threads@FreeBSD.ORG Fri Apr 11 11:11:17 2003 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 409F337B401; Fri, 11 Apr 2003 11:11:17 -0700 (PDT) Received: from sccrmhc02.attbi.com (sccrmhc02.attbi.com [204.127.202.62]) by mx1.FreeBSD.org (Postfix) with ESMTP id 65C5143F3F; Fri, 11 Apr 2003 11:11:16 -0700 (PDT) (envelope-from julian@elischer.org) Received: from interjet.elischer.org (12-232-168-4.client.attbi.com[12.232.168.4]) by sccrmhc02.attbi.com (sccrmhc02) with ESMTP id <200304111811140020070oc3e>; Fri, 11 Apr 2003 18:11:15 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id LAA99100; Fri, 11 Apr 2003 11:11:13 -0700 (PDT) Date: Fri, 11 Apr 2003 11:11:11 -0700 (PDT) From: Julian Elischer To: Daniel Eischen In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: David Xu cc: freebsd-threads@freebsd.org Subject: Re: patch for %gs saving X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Apr 2003 18:11:17 -0000 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 > >