From owner-freebsd-threads@FreeBSD.ORG Fri Apr 11 06:01:09 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 8636637B401; Fri, 11 Apr 2003 06:01:09 -0700 (PDT) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id B08FC43F75; Fri, 11 Apr 2003 06:01:08 -0700 (PDT) (envelope-from eischen@pcnet1.pcnet.com) Received: from pcnet1.pcnet.com (localhost [127.0.0.1]) by mail.pcnet.com (8.12.8/8.12.1) with ESMTP id h3BD12Bg016193; Fri, 11 Apr 2003 09:01:02 -0400 (EDT) Received: from localhost (eischen@localhost)h3BD11Fa016190; Fri, 11 Apr 2003 09:01:01 -0400 (EDT) Date: Fri, 11 Apr 2003 09:01:01 -0400 (EDT) From: Daniel Eischen To: Julian Elischer 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 13:01:10 -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). 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