Date: Wed, 6 Aug 2003 15:28:52 -0400 (EDT) From: Daniel Eischen <eischen@vigrid.com> To: Marcel Moolenaar <marcel@xcllnt.net> Cc: threads@freebsd.org Subject: Re: KSE/ia64: a quick update Message-ID: <Pine.GSO.4.10.10308061501010.26840-100000@pcnet5.pcnet.com> In-Reply-To: <20030806185530.GA893@athlon.pn.xcllnt.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.GSO.4.10.10308061501010.26840-100000>