Date: Mon, 7 Jan 2002 01:52:28 -0500 From: Jake Burkholder <jake@locore.ca> To: Bernd Walter <ticso@cicely8.cicely.de> Cc: Terry Lambert <tlambert2@mindspring.com>, Alfred Perlstein <bright@mu.org>, Dan Eischen <eischen@vigrid.com>, arch@FreeBSD.ORG Subject: Re: Request for review: getcontext, setcontext, etc Message-ID: <20020107015228.E39321@locore.ca> In-Reply-To: <20020106113847.A15885@cicely8.cicely.de>; from ticso@cicely8.cicely.de on Sun, Jan 06, 2002 at 11:38:48AM %2B0100 References: <3C37E559.B011DF29@vigrid.com> <20020106032709.A82406@elvis.mu.org> <3C381B48.AADDCA2B@mindspring.com> <20020106113847.A15885@cicely8.cicely.de>
next in thread | previous in thread | raw e-mail | index | archive | help
Apparently, On Sun, Jan 06, 2002 at 11:38:48AM +0100, Bernd Walter said words to the effect of; > On Sun, Jan 06, 2002 at 01:39:20AM -0800, Terry Lambert wrote: > > Alfred Perlstein wrote: > > > * Dan Eischen <eischen@vigrid.com> [020105 23:36] wrote: > > > > Is there a reason that getcontext and setcontext need to be > > > > system calls? > > > > > > Atomicity? > > > > To flush register windows on setcontext() on SPARC. > > wflush isn't a priviledged instruction and usualy emulated on < sparcv9. > mit-pthreads use it from userland. Yes, this (flushw) is the best way to flush the windows on v9 at least. > > Are there any performance reasons to flush windows in kernel? No, doing so is actually more complicated (slightly) due to having to use copyout and due potentialy having to deal with 32bit applications running on 64bit kernels. It is easier if the spills look like normal spills. > AFAIK wflush makes an exception for each window on it's own so I could > imagine a possible difference. > Or am I overseeing something? It does, but these are trivial exceptions. They only exceute about 20 instructions in kernel mode (a store to the user stack for each register plus bookkeeping). What's complicated and expensive is a page fault inside of a spill handler due to needing to grow the user stack. But this isn't the normal case. In any case, I think that these can be implemented in userland for sparc64 and I will do so as soon as I have time. We don't build libc_r yet for sparc64, so I don't mind if these are committed before the sparc64 versions are done. Jake To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020107015228.E39321>