From owner-freebsd-threads@FreeBSD.ORG Fri Apr 11 05:43:22 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 3421337B401; Fri, 11 Apr 2003 05:43:22 -0700 (PDT) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1D10343F93; Fri, 11 Apr 2003 05:43:21 -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 h3BChEBg013986; Fri, 11 Apr 2003 08:43:14 -0400 (EDT) Received: from localhost (eischen@localhost)h3BChDCK013983; Fri, 11 Apr 2003 08:43:13 -0400 (EDT) Date: Fri, 11 Apr 2003 08:43:13 -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 12:43:22 -0000 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). -- Dan Eischen