From owner-freebsd-threads@FreeBSD.ORG Wed Aug 6 12:28:53 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 83CD837B401 for ; Wed, 6 Aug 2003 12:28:53 -0700 (PDT) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id DB72D43FAF for ; Wed, 6 Aug 2003 12:28:52 -0700 (PDT) (envelope-from eischen@vigrid.com) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mail.pcnet.com (8.12.8/8.12.1) with ESMTP id h76JSquN001604; Wed, 6 Aug 2003 15:28:52 -0400 (EDT) Date: Wed, 6 Aug 2003 15:28:52 -0400 (EDT) From: Daniel Eischen X-Sender: eischen@pcnet5.pcnet.com To: Marcel Moolenaar In-Reply-To: <20030806185530.GA893@athlon.pn.xcllnt.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: threads@freebsd.org Subject: Re: KSE/ia64: a quick update X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: deischen@freebsd.org List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Aug 2003 19:28:53 -0000 On Wed, 6 Aug 2003, Marcel Moolenaar wrote: > Gang, > > Given the panics that Daniel is having on pluto1 it's probably a > good idea to fill people in on the status of KSE/ia64: First, thanks for your help on ia64. As I've found out, there still seems to be a lot more that needs to get done (in general, not KSE specific), and you seem to be the only one working on it. > The groundwork is finished. I practical terms this means that I/O > bound threads work to its fullest extend. There's just one tiny > little annoying and complicated thing: thread_userret(), and > consequently thread_export_context() can be called for interrupts, > traps and faults as well. Since syscalls are not implemented as > traps, we have two distinct paths into (and out from) the kernel. > > One (the syscall) is synchronous WRT to program execution and the > other (interrupts) is asynchronous. Synchronous contexts don't > have scratch registers in them. Asynchronous context need to have > them. This is not the hard problem: just add some flags to indicate > what parts of the context are valid and thus should be restored > and we're ok. > > The problem is when we preempt an interrupted thread, export the You mean when an interrupt thread preempts an SA thread? And this would be while it was in userland, not in the kernel? > context to the UTS and do an upcall. We end up having an async. > context in userland. I'm not sure at this time what we should do > with it. We have the following options: > > o Extend _ia64_restore_context() so that libkse can restore async > contexts. The downside is that it will very likely cause a > disabled high FP trap, which results in the process having the > high FP registers enabled. A performance hit. (see also below) Having to know about 2 different contexts isn't too new. Alpha may need the same thing since sigframes and trapframes are not the same (why?). > o Have _ia64_restore_context() call setcontext() for async contexts > and do the work in the kernel. Restoring the high FP will not > result in the enablement of the high FP registers, because we > can restore them to the PCB. They will be loaded into the CPU > when there's a need for them (which may be never). This can't really work without a special system call because you need to atomically set the thread mailbox pointer. If you want to add a syscall that does that, then that could be an option. Or, _ia64_restore_context() could be made to munge an async context so that it first returns to a function that can set the mailbox before returning to the interrupted context. The key is that once the mailbox pointer has been set, the threads context in the mailbox cannot be accessed again. A very slow method for doing that would be do use something like signalcontext() to copy the saved context out of the mailbox before setting the mailbox pointer and returning to it. Hmm, I guess you could just copy the context to a stack variable in _ia64_restore_context(): _ia64_restore_context(...) { if (context is synchronous) /* normal restore */ else { ucontext_t uc; uc.uc_sigmask = _thr_process_mask; bcopy(&ctx.uc_mcontext, &uc.uc_mcontext, sizeof(uc.uc_mcontext)); /* set mailbox pointer */ setcontext(&uc); } } If you chose this route, or something similar that needs a system call, you might optimize the kernel. You might only need to make an upcall when the KSE's quantum expired instead of whenever a thread was interrupted. Or perhaps when there are no unblocked threads in the kernel that require an upcall to notify the UTS, there's no need to make an upcall. In regards to the high FPU thing. Can't you tell the UTS via the exported context whether a high FPU restore is necessary? Just something that will let the restore avoid the trap into the kernel and getting tagged as being a high FPU process... -- Dan Eischen